Tauri 2 - iOS, a Feedback

[jrouaix]

Hello everyone,

First of all, I want to extend my sincerest congratulations to the creators and contributors of Tauri.
This project is a breath of fresh air for anyone looking to create truly cross-platform applications using simple web technologies.
The packages are ultra-lightweight, and when performance is needed... Rust is here! Blazingly fast!

That being said, the announcement of Tauri 2 Beta and mobile support made us perhaps too optimistic about the imminent maturity of iOS support. This present feedback will show that we tried hard but with moderate success.

Tauri still seems promising to us, but it seems that some design choices were made too quickly and won't bring much benefit in the future. Therefore, I would like to summarize them in this issue, after a review by my colleagues.

My goal here is not to rant, only to contribute in the best way I can now, share views and expose to comments.

Tauri 2 Quick Start

It works. It works well and fast, on the emulator and on the device. It inspires confidence.

A bit of context

Simply put, our application uploads a big file, and so we need to share a file to this application.

Going past the boilerplate project

To share a file with the application, we had two methods:

• a Document Application => but I couldn't figure out how to retrieve the sharing context in Rust (provided by the SceneDelegate component in Swift).
• a Share extension => in Swift, which, after placing the file in the group container, calls the main application via an openurl()

It was complex to figure out how to integrate the share extension, which files to keep/not keep in the gen directory.

Improvement Suggestions:

Could you document the iOS build steps, the tools called, in what order, the files that are generated once and that we can modify, and the ones that should not be modified at all.

Unable to deploy the application on the simulator with the share extension

As soon as we complexified the Xcode project with our share extension, we could no longer deploy on the simulator. The developer experience was severely degraded. We never managed to fix this issue.

• https://discord.com/channels/616186924390023171/1252189105748705351
• [bug] failing to run tauri2 with app extension on the iOS Simulator #10074
• https://github.com/mrguiman/tauri2-test/tree/app-extension-fix-attempt
• https://github.com/mrguiman/tauri2-test/blob/app-extension-fix-attempt/src-tauri/gen/apple/project.yml

Build Shenanigans

From what we understand, the iOS build steps are as follows:

• cargo tauri ios init => scaffolds the project
• cargo tauri ios build =>
  • builds the front part of the app
  • then calls xcodebuild
    • which will call cargo tauri ios xcode-script with more environment variables
      • it will get the configurations/options by launching a web server 🤯 here
      • and build some .a files for xcodebuild to use
  • then xcodebuild can finish the build

The iOS configuration is too poor to hope to make applications more complex than the quickstart:

tauri/tooling/cli/schema.json

Line 2694 in 11aa774

"MacConfig": {

So we had to change the project.yml directly, and it seems its the tauridiomatic way. Good to know.

• [bug] cargo tauri ios build with -c configuration override fails to build #9970
• https://github.com/tauri-apps/cargo-mobile2/blob/46c0a4209bafa456ce1fca2ea0265c382a1f21bb/src/apple/cli.rs
• https://discord.com/channels/616186924390023171/1209442310434193471

Improvement Suggestions:

IMHO, I think Xcode should not call Tauri again. I think Tauri should generate what is needed for Xcode, and then let Xcode do its job, and allow us to modify these steps if needed to adapt to the needs of a complex application.

tauri => xcode if possible please / NOT tauri => xcode => tauri => xcode

Apple's guidelines clearly state these points. They expect deep iOS/system integration according to the app's purpose, not just a revamped website. So you'll have many Tauri users mixing Tauri with other native objc or swift parts in the same bundled app.

Signing Shenanigans

This was also much harder than expected, but it's probably much more the fault of the Apple ecosystem than Tauri.

https://discord.com/channels/616186924390023171/1247183908588617828
#9963

Conclusion

From start to finish, this development has been my worst developer experience in years.

• largely because of the discovery of Xcode and the Apple environment:

  • experienced Swift developers I talked to avoid using Xcode and prefer other editors
  • the main .xcodeproj file is so despised that the community created tools to replace it (xcodegen)
  • nothing is easy on this platform, nothing is possible without multiple cryptographic signature!
  • the documentation is either anemic or tedious, nothing works easily once you step outside the quickstarts

• partly because Tauri relies on other technologies that are themselves immature.

• but on the other hand, there are things in Tauri that worry us for its wider adoption:

  • The xcode build steps that pass and re-pass through Tauri
  • Incomprehensible things (the websocket during the build?)
  • A succession of tools too difficult to grasp, it's like a 15-band billiards game, it really needs to be simplified.

Is iOS support really a beta version ?

Many plugins are not yet supported everywhere, and the documentation is not up to date.
And it's normal, there's a lot of work. I dont mean to dunk on your amazing work while my only contribution is trying to use. We were a bit too optimistic about the maturity of Tauri 2. In my opinion, this is not a beta, meaning in the process of stabilization. It's more like an alpha, meaning in development.

https://github.com/tauri-apps/plugins-workspace/blob/40ef9a818fb03457819c1d72ea84de57fbf868ba/plugins/deep-link/src/lib.rs

Thank you again

Thank you for your attention and for considering our feedback. Again it's not about the current state, it's about the future of Tauri, which we believe in.

[simonhyll]

Read your feedback and it's all fair, no offence taken 🙂 Might I interest you in joining in on our next 2 events we have on Discord? The next one is related to documentation development and I think it might be nice to get your input on the docs more directly. The second one is our regular office hours (don't let the name scare you, it's a community call), where we share updates on various topics and time permitting open up for a Q/A session.

The documentation points are very much known and we're actually considering the 2.0 milestone in tauri-docs to be a blocker for a 2.0 Tauri release. So if you check that list hopefully you'll find all your issues with documentation mentioned. If you don't, please please please start making issues in tauri-docs so we can get things tracked to be dealt with, if there's not an issue for it we probably aren't even aware that it's an issue. Note that there's also a 2.x milestone, which are not considered blockers, so if you find your issue in there and disagree that 2.0 could be released with those issues unresolved please let me know in the #docs channel on Discord and we'll get that sorted.

Regarding whether the project can be considered to be in beta, that's more related to API's exposed and tooling decisions, not so much with implementation details such as whether a websocket gets launched. Tauri will never stop being in development, it's never a finished product, alpha is more about where you're allowed to make major breaking changes freely, beta should limit the breaking changes to a minimum, release candidates aren't allowed to break anything, then you make a release. So based on that we're currently in beta because we only make breaking changes if it's absolutely necessary, and are actually at the point where we're looking at maybe going into RC candidates because we don't plan on making any more breaking changes.

There are going to be annoyances and issues in the release 2.0 version as well, it's by no means guaranteed to be bug free. Implementation details will likely be updated in 2.x, 1.0 is very different after all from 1.7, but if you want API alterations to happen for 2.0 then you'll need to get involved with the projects development asap. And ofc keep in mind that as an open source project we have about as much time to work on Tauri as your team does, meaning if something looks wrong then you're more than welcome to start contributing to the project, I myself do most of my contributions late at night after all my other work is done for the day. But feedback is definitely also a way of contributing so again, no offence taken, and would love to hear more feedback, it's the only way the project can grow, by having its flaws pointed out, even if you decide you don't have the time to fix all issues yourself then us that do take the time from our days to try to fix issues will usually focus on issues that we ourselves encounter, and I personally have very little interest in iOS which is why that side of the project contribution wise (from me, who's mostly engaged in the documentation side of things) has been very lacking, so sorry about that 😅

[mrguiman]

We're definitely considering careful contributions, we've been poking around a lot but have yet to contribute code because we're lacking some knowledge of the project or it would mean big architectural changes. The point about the tauri build process is actually quite high on our list because we're convinced that tauri cli might actually be overreaching here (at least in the case of iOS) so it was important for us to start discussing this with the core team :)

[mrguiman]

Quick update, Apparently we needed to run the app with tauri dev --open for it to work in the simulator. Not ideal but better than nothing!

[super-fun-surf]

And what is the state of filesystem support for rust in iOS. is there an example of how to write a simple file and read it using an allowed path?