> For the complete documentation index, see [llms.txt](https://docs.realmacsoftware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.realmacsoftware.com/classic/developers/themes/theme-info.plist.md).
# Theme Info.plist
The Info.plist stores basic information about the Theme, such as its name, author, and version number.
It supports the following keys:
```
RWAddonAuthor, string
RWAddonManagerIconAsset, string
RWAddonSupportURL, string
RWThemeIsResponsive, bool
CFBundleIdentifier, string
CFBundleShortVersionString, string
CFBundleVersion, string
SUFeedURL, string
```
Here is an example of an info.plist from a standard theme:
```xml
CFBundleIdentifier
com.realmacsoftware.future
CFBundleShortVersionString
1.0
CFBundleVersion
1.0
RWAddonAuthor
Realmac Software
RWAddonSupportURL
http://realmacsoftware.com/support
RWBannerOptions
RWThemeBannerFallbackImage
images/banners/default.jpg
RWThemeBannerImageRecommendedHeight
720
RWThemeBannerImageRecommendedWidth
1080
RWThemeIsResponsive
RWThemeSupportsBannerImages
```
### Theme Updates via Sparkle
RapidWeaver Classic offers a way for developers to offer theme updates via sparkle. Theme updates work exactly the same way as plugin updates have always done.
To take advantage of this feature you’ll need to add a `SUFeedURL` key to the `Info.plist` of your theme. The `SUFeedURL` key should reference the Sparkle RSS feed on your server.
If you’re unfamiliar with the XML AppCast format there’s some documentation on the Sparkle website, here: [Publishing an update - Sparkle: open source software update framework for macOS](https://sparkle-project.org/documentation/publishing/)
### Theme Version Numbering
When comparing releases, we’ll look at the `CFBundleVersion` field in your addon’s Info.plist file. If this isn’t increased, we’ll assume it’s not an updated addon. Apple has this to say about `CFBundleVersion`:
> CFBundleVersion (String - iOS, OS X) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle. The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero. The string should only contain numeric (0-9) and period (.) characters. Leading zeros are truncated from each integer and will be ignored (that is, 1.02.3 is equivalent to 1.2.3). This key is not localizable.
When displaying the version string to users, we’ll use `CFBundleShortVersionString` . This isn’t used for calculating updates - it’s only used in UI. Apple has this to say:
> CFBundleShortVersionString (String - iOS, OS X) specifies the release version number of the bundle, which identifies a released iteration of the app. The release version number is a string comprised of three period-separated integers. The first integer represents major revisions to the app, such as revisions that implement new features or major changes. The second integer denotes revisions that implement less prominent features. The third integer represents maintenance releases.
> The value for this key differs from the value for `CFBundleVersion` , which identifies an iteration (released or unreleased) of the app. This key can be localized by including it in your `InfoPlist.strings` files.
In most cases, you’ll want these to be the same value.
When comparing version numbers, no other fields are used. To be totally clear, do not use RWVersion in your Theme.plist file.
Plugins should also set the RWPluginAPIVersion field in their Info.plist and we’ll change certain behaviour based on their selection. This does not increment in line with the RapidWeaver release version.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.realmacsoftware.com/classic/developers/themes/theme-info.plist.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.