I'm producing a Compose/iOS App using `compose.experimental.uikit.application`. Is it a correct obs...

# compose-ios

[darkmoon_uk]

I'm producing a Compose/iOS App using compose.experimental.uikit.application.

Is it a correct observation that this is currently incompatible with the Cocoapods plugin alphabet yellow question Detail in 🧵 👉

[darkmoon_uk]

In short: I'm exercising the common need to include a framework that exists as a file-based Cocoapod.

Linking this against another library project works fine, so I'm confident in the Cocoapod itself; however including it in this uikit.application appears to neither copy the library to output, nor apply any linker flags as I would expect.

[darkmoon_uk]

Workaround: I've included the Framework manually as a resource and applied -F and -framework flags to link it; and this works... ✅

🤔 However; this reveals another apparent limitation of `uikit.application`: It doesn't seem to respect any additional resource folders registered with resources.srcDir(...) in the iOS source-set, meaning I am forced to copy the framework into uikitMain/resources which is not ideal. I tried symlinking from this location as well but this produced... indeterminate behaviour, sometimes the resource was copied, sometimes not, probably to do with when/how resources get snapshot for the build at a filesystem level.

[Landry Norris]

I think compose.experimental.uikit.application is mainly meant for JetBrains to do testing, more so than something built for production apps (although the org.jetbrains.apple plugin looks promising once it’s more stable and documented). I’d recommend doing a normal XCode project for now.

[darkmoon_uk]

@Landry Norris To some degree the risk is acceptable to me as I'm using the uikit.application to produce an internal test application rather than for production. However I'd move to XCode project if it provides the path of least resistence...

Have you seen that it's practical/possible to invoke Compose/iOS via the fuller XCode project route?

[Landry Norris]

Yes. The Application method returns a normal ViewController

[darkmoon_uk]

Great, thanks for confirming, I'll look into it.

[Landry Norris]

I use the XCode project for an internal test app. I have a throwaway VC that iOS starts, then immediately uses a navcontroller to switch to the result of Application. I'm sure there's a better way to do this, but I haven't put in the time.

[darkmoon_uk]

Out of interest; we've got the iOS tech positioned currently as 'internal test target' - definitely useful to Devs but supporting no promises to the business - with a potential route to release as things get more mature. Other targets already destined for release.

[darkmoon_uk]

@Landry Norris If I get something going that doesn't require a throwaway VC I'll share with you.

[Landry Norris]

That sounds cool. Now that Popup support exists (hopefully a built-in DropDownMenu will come soon), iOS compose is technically complete enough to fully switch a project over, but performance is too much of an issue currently. Can't wait to see Compose for iOS become more complete. Was talking today with someone about how much easier a feature would be if we could use Compose on all platforms.

[darkmoon_uk]

I daren't even whisper about Canvas Web yet - that would almost be a threat(!) 😅 ...and anyway too early. But looking forward to it in the next life.

[darkmoon_uk]

Yes performance is really poor at the moment - doesn't even stand up against React Native; though it sounds like JB have a good handle on how to improve this once it bubbles up the priorities.

[Landry Norris]

Yeah. The biggest limitation is definitely time.

[darkmoon_uk]

...and recovering from the recent organisational shock.

[darkmoon_uk]

@Landry Norris Sorry to ask again but there are so many options(!) are you using the new-ish Xcode project generating 'Apple Plugin', or the vanilla Xcode project with Run-Script call out to Gradle/Konan setup?

[Landry Norris]

I followed the KMM cocoapods instructions, so it's vanilla XCode