WatchOS

[JeremyK]

Is it still the case we can’t create a watchOS companion app with Fire? I notice there’s a static library option that mentions watchOS, but I have no clue what I’d need to do to be honest, I just noticed https://elements.docs.remobjects.com/Platforms/Cocoa/ToffeeVsIsland/ says it’s not possible.

I’m wondering if I can make the app in Xcode and somehow use this library, but not sure.

[mh (marc hoffman)]

@JeremyK

Is it still the case we can’t create a watchOS companion app with Fire? I notice there’s a static library option that mentions watchOS, but I have no clue what I’d need to do to be honest, I just noticed https://elements.docs.remobjects.com/Platforms/Cocoa/ToffeeVsIsland/ says it’s not possible.

You can, yes. I recently did this for the Weather app (or rather, had CodeBpot do it ;). I think a simple Swift wrapper was needed, but I’ll check.

[mh (marc hoffman)]

I checked how we did this for the Weather app, and the recollection about the Swift wrapper was slightly off: the Watch app itself is built with Elements. Apple Swift is only used for the separate complication extension, where we use WidgetKit and SwiftUI.

The overall setup is:

• Elements/Oxygene: the WatchKit app’s logic, data handling, and interface controllers.
• WatchKit storyboard: the app’s screen layout.
• A small Apple Swift target: the WidgetKit timeline provider and SwiftUI views for complications.
• Fire/EBuild: builds and packages the projects, calling xcodebuild for that one Swift target.

We’ve had this accepted through TestFlight/AppStore and running on a physical Watch, including the complications.

The project structure looks roughly like this:

iPhone app                         [Elements]
└── Watch app bundle               [Elements]
    ├── WatchKit runtime extension [Elements/Oxygene]
    └── WidgetKit extension        [Apple Swift]

More concretely, the steps were:

1. Create the Watch app and its WatchKit extension as Elements projects.

   The Watch app project contains the storyboard, icon, and other resources. The runtime extension contains the Oxygene code and references Foundation, WatchKit, and Elements RTL.

   The important runtime project settings include:

   <SDK>watchOS</SDK>
   <OutputType>Extension</OutputType>
   <CreateAppBundle>True</CreateAppBundle>
   <BundleExtension>.appex</BundleExtension>
   <IsWatchKitExtension>True</IsWatchKitExtension>
   

   The extension uses WKExtensionDelegate and WKInterfaceController, with outlets and actions connected to the storyboard. This part does not require an Apple Swift wrapper.

2. Keep the application logic in Elements.

   In our case, the app downloads a small JSON weather summary, validates and caches it, and displays the current conditions. It can fetch the data directly on the Watch without requiring the iPhone app to be running.

   That is ordinary application code using Foundation and Elements RTL; there is no need to move it into Xcode.

3. Add a small Xcode target if you want modern complications.

   This is where we used Apple Swift: a WidgetKit extension with a timeline provider and SwiftUI views for the circular, corner, inline, and rectangular complication families.

   Ours also has a small Foundation-based fetch/cache helper. The complication runs separately from the WatchKit app and reads the same JSON feed, so our implementation does not need a language bridge or an App Group.

   If you don’t need complications, you can leave this target out entirely.

4. Let EBuild handle the project dependencies and embedding.

   The iPhone project references the Watch app project, which references the WatchKit runtime extension. A pre-build script invokes xcodebuild for the WidgetKit target, and the resulting .appex is included as an app resource under the Watch app’s PlugIns folder.

   The script passes through the configuration, version, bundle identifier, and signing settings. It only builds the Apple Swift extension; the Elements projects use normal EBuild project references.

5. Configure signing and versions for the nested bundles.

   Each app/extension needs the appropriate bundle identifier, entitlements, and provisioning profile. EBuild signs the nested components before packaging the containing app.

   We also added BundleVersionFromProject support so the Watch projects inherit the iPhone project’s version. That resolved version is passed to the Swift build too, leaving one version number to maintain.

6. Check the SDK and runtime architectures together.

   Our current setup targets watchOS 26 or later and builds device binaries for both arm64 and arm64_32. The imported SDK and the Elements runtime libraries need the corresponding slices. Reimporting the Apple SDK alone does not update libToffee, libSilver, or libElements.

   We fixed several watchOS build, signing, and packaging issues in EBuild while doing this, so the exact Elements build you use matters.

One caveat: this app uses the older WatchKit/storyboard UI model, which Apple marks as deprecated. It worked for our app and passed TestFlight processing and App Store approval. A fully SwiftUI-based Watch application would be a different arrangement, with more of the UI hosted in an Apple Swift target.

So yes, a companion Watch app is possible from Fire. For our approach, the Apple Swift portion is confined to the WidgetKit complications; the Watch application itself remains an Elements project.

hth

[JeremyK]

Awesome, thanks marc, I shall investigate. I just want to add something because it’s there but the users may like for my tower visiting app to have something that simply shows some info of a nearby tower or a simple add a visit function. I also thought maybe a similar simple complication may be useful.

[JeremyK]

@mh

So yes, a companion Watch app is possible from Fire.

Ta da !

Thanks for the pointers. That’s the simulator working with some basic functionality!

[mh (marc hoffman)]

Awsome! happy ringing!