tauri icon indicating copy to clipboard operation
tauri copied to clipboard

[feat] Android/iOS support

Open wusyong opened this issue 2 years ago • 15 comments

Wry has mobile support for a while and I've update a few commits to make it easier to develop with. Here's the notes for using wry on mobile ends: https://hackmd.io/XIcEwk4GSxy8APZhSa0UnA?view

Before we add mobile support to tauri, I would like to gather more feedbacks on this. There are a few issues we have to discuss and decide.

How do we setup a Tauri mobile project?

Wry uses a custom cargo-mobile and it has to modify a few things to make it works especially on Android. We couldn't simply use NDK due to restriction of its own webview. This brings a lot of limitations on Android, and writing Rust code is very inconvenient. It usually would be a lot easier to just write plan Kotlin.

Many traits defined in tauri-runtime also don't apply to mobile. There's no menu, global shortcut, system tray etc. And many window methods don't work either.

I think we probably want to merge the custom cargo-mobile into our own CLI. But I'm not sure how do we do it and maintain it. Perhaps we can make a tauri template on cargo-mobile first and think about next step after this.

Project structure must comply to Xcode and Android studio

Cargo-mobile generate templates for Xcode and Android studio. They have to obey the structure of these IDE. Cargo-mobile will usually generate a shared assets directory and I've made custom protocol to follow it in wry. But this still have some limitation especially on Android (again): https://hackmd.io/XIcEwk4GSxy8APZhSa0UnA?view#Android2

Custom protocol on Android is fixed. I didn't add FFI to rust side because if you know the signature of JNI, You_already_know_how_verbose_It_HAS_TO_BE. I hope this limitation would be fine for tauri. Otherwise, we'll have to think again how to support it.

Environment setup is still difficult

I've tried several weeks to ease the pain but there are still a lot of issue across different plantforms and archs. Cargo-mobile only supports macOS and Linux. To be honest, if you want to develop iOS app, you must use a macOS device.

Different architectures also break cargo-mobile in a few places. I didn't know how to fix it, and hence could only add notes about it. Ideally, it should just do the work with cargo apple/android build and then cargo apple/android run.

So before we start working support of tauri, I really hope someone who is interested could help testing the mobile support on Wry. And see what would be the blockers and how do we improve it.

wusyong avatar Apr 11 '22 05:04 wusyong

Is this also a right place to ask/discuss about the mobile support before its being actively worked on it?

For example, it may be the least priority currently but best to discuss before it may be more difficult to implement it in the future is for example widget support for iOS/Android which has very limited WebView support.

Disclaimer, I havent used Tauri yet, but def interested to use + support Tauri with the cross-platform (including mobile) support 👍

YanDevDe avatar May 17 '22 12:05 YanDevDe

I'm interested in this feature. What can I do to help move things forward?

jhutchins avatar Jun 13 '22 13:06 jhutchins

We now has a branch feat/ios-build for ios experiment. Android will follow later. You can try it by installing my fork of cargo-mobile. Follow this note and you should get the app working on both simulator and device.

Currently the problem I couldn't solve is environment setup. If you know about Xcode or Android Studio. Welcome to investigate these issues.

wusyong avatar Jun 14 '22 06:06 wusyong

I'm mostly interested in android at the moment. I've rebased the feat/ios-build branch onto current dev and made some minor tweaks to fix build issues with android on this branch (and made a different build of wry for android as well).

There's some issues with the template code from the cargo mobile build for android. There's this import line

use wry::application::{android_fn, platform::android::ndk_glue::*};

Which first is an issue because it's using wry when it's not included in the Cargo.toml and second I don't know what branch of wry would have android_fn or platform::android::ndk_glue

Additionally there seems to be an issue with the mobile builds when the newest versions of tauri are added to the branch because I get this error in the final step of the build

error[E0433]: failed to resolve: could not find `embed_plist` in `tauri`
  --> src/lib.rs:45:14
   |
45 |         .run(tauri::generate_context!())
   |              ^^^^^^^^^^^^^^^^^^^^^^^^^^ could not find `embed_plist` in `tauri`
   |
   = note: this error originates in the macro `tauri::generate_context` (in Nightly builds, run with -Z macro-backtrace for more info)

which I haven't been able to resolve yet. I'm not really clear on what's being done with the generate_context macro and I can't figure out where it's referencing emded_plist at all.

jhutchins avatar Jun 20 '22 23:06 jhutchins

I was able to get an android variant that would build by rebasing my tauri branch off of the v1.0.0 tag instead of the head of dev and by making these changes to src/lib.rs

diff --git a/src/lib.rs b/src/lib.rs
index becfce3..d5609ed 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -2,8 +2,6 @@
 extern crate log;
 
 use anyhow::Result;
-#[cfg(target_os = "android")]
-use wry::application::{android_fn, platform::android::ndk_glue::*};
 
 #[cfg(target_os = "android")]
 fn init_logging() {
@@ -36,8 +34,6 @@ fn _start_app() {
 #[no_mangle]
 #[inline(never)]
 pub extern "C" fn start_app() {
-    #[cfg(target_os = "android")]
-    android_fn!(io_nit, temp);
     _start_app()
 }

with just a little configuration in Android Studio I got the project building and deploying to an emulator (I used these instructions to choose the build variant). Now I just need to figure out why it crashes immediately on launch.

jhutchins avatar Jun 21 '22 12:06 jhutchins

Also, what's the plan for the gen subdirectory? By default it's excluded by the .gitconfig but obviously the project won't build without it there. Should that be removed from the .gitconfig and actually be checked in, or would some tauri build tool just generate that at build time using information from mobile.toml?

jhutchins avatar Jun 21 '22 12:06 jhutchins

I do hope to see Mobile support for it soon, once it implements, I can finally stop using ReactNative and Cordova and switch to this instead... When do you think this would become a feature? 2025? Or am I being a bit too optimistic?

WeebNetsu avatar Jun 24 '22 07:06 WeebNetsu

the plan is to have initial support implemented this year.

FabianLars avatar Jun 24 '22 09:06 FabianLars

Is this the best source of truth for android/iOS progress? Are there action items that newer contributors could help out with, or provide alpha testing for?

Supporting iOS/Android is an absolute game changer.

matthewoates avatar Aug 11 '22 03:08 matthewoates

Is this the best source of truth for android/iOS progress? Are there action items that newer contributors could help out with, or provide alpha testing for?

We have a #mobile channel in discord. Tauri can technically support both platforms now. But we might need to refactor a few places to make it work more excellent in tauri's ecosystem.

wusyong avatar Aug 12 '22 07:08 wusyong

Will there be any limitations regarding sidecars when we have Android/iOS support? I'm wondering how easily they will be supported in mobile.

jvican avatar Aug 18 '22 17:08 jvican

Look forward to this feature

Lydanne avatar Aug 19 '22 02:08 Lydanne

There are a few pain points with Tauri, especially the disk usage on the build machine and the strictness of Rust, but another one that deserves attention, although it's not as problematic, is the difficulty when trying to figure out the actual status and roadmap of the project.

I use Tauri for some personal Linux-only stuff, and the possibility of using Tauri to write mobile apps really excites me, however it's very hard to figure out the situation on that front. Crystal-lang did something that I consider VERY useful by tracking the Windows support in an Issue (Here), but I'm sure there are tons of ways that are just as good, or even better.

What matters is having some single-source-of-truth, tracking the general situation of everything related to some complex feature, while leaving out the details. From what I gather this is at a pretty early stage, and lots of things will be added and/or broken down into multiple items, but it would still help to have some list of next steps.

To give a more tangible example of what I mean, we might start with a few things mentioned above, to which I'm adding some stuff I consider relevant:

Project Structure Compatibility:

  • [ ] XCode;
  • [ ] Andoid Studio;

Platform support:

  • [ ] cargo-mobile;
  • [ ] wry;
  • [ ] compilation

APIs (Only a few as examples, there are loads of APIs after all):

  • [ ] Push Notifications;
  • [ ] Camera;
  • [ ] GPS;
  • [ ] Storage/Cache;

There's also the matter of mobile installation, and possibly data (Mobile/Wifi. Not sure whether either is available by default, but it's still helpful to know whether those work).

Then, as development advances, those boxes would be ticked, more items would be added, descriptions would be added etc.

Something like that would also allow people to decide whether they may be able to contribute or note. I, for instance, have near zero experience with mobile, except for Progressive Web Apps, and I'm far more experienced with Ruby and other dynamic languages than I am with Rust. But I do have over a decade of experience working as a programmer, and if you count my teens when I wasn't paid that jumps to about 2 decades. As a result I do know my way around types and compilers pretty well, and new languages usually don't pose much of a challenge, at most they're a but uncomfortable and require a bit more time.

Point being: I may be able to help, depending on what's needed, and I'm sure there are others in the same situation. Having some source of truth for that, with a roadmap, would be very helpful, especially considering the comments from @matthewoates, @jhutchins, @YanDevDe etc.

Not sure who should maintain the list though, I believe it's you, @wusyong, as you're on the Tauri Team and opened this issue, so I posted here, but if I'm mistaken and it's someone else, I hope you'll bring this to the attention.

Finally, I'd love to contribute with this. I've been using PWAs and they're quite amazing, but PWAs are nowhere near native feature-wise, and native is just way too troublesome when you only want to have a couple tools you're writing to use on your PC to ALSO work on your mobile devices. Not to mention Java, whenever I think of it my only desire is to "kill it with fire"... Rust, on the other hand, is great, and web technologies are ok, so having Tauri would really help a lot. I hope this helps with figuring out how to coordinate efforts, and I'll try to contribute what I can.

frnco avatar Sep 18 '22 23:09 frnco

@frnco I don't disagree with your sentiment, the communication could be better regarding this feature. The good news it actually works reasonably well at this point. I actually have a running mobile version of my app on android.

As mentioned above primary coordination and communication had been happening in the #mobile channel of the discord server. The HackMD link further up in the thread I think has aged a little, but I think it's still correct regarding the environment setup.

If you install the tauri cli utility from the next branch you'll have a super powered cargo tauri command that includes subcommands for Android and iOS. I find the android dev subcommand to be especially useful and surprisingly slick.

If you want to create release builds the commands are in place, but you need to make some undocumented changes to make signing of the android release work. But with a little elbow grease and adventurous spirit you can get everything working.

I'm not a part of the Tauri dev team (although I have contributed code to make mobile work), so I can't speak for them, but from my perspective all that's really missing for an alpha release is formal documentation around some of the topics I mentioned (environment setup, release signing). My guess is there's likely a alpha by Halloween, but like I said, I don't speak for the team and I'm not aware of priorities, official timeline or schedule.

jhutchins avatar Sep 27 '22 11:09 jhutchins

hey @frnco - thanks for the desire to help, and I hear what you are saying. For a long time, we had a roadmap - and then a lot of the features got closed. And the stuff left to do seemed to not be enough to warrant a whole roadmap - so a design decision was made to just shelve that. We are still a humble bunch of volunteers, so please excuse the "rough edges"

That said, we generally prefer to have our planning discussions inside of our voluntary working group, which you (and anyone) is welcome to join. Please visit our discord and speak up there.

And yes, we plan to bring out the alpha of mobile in the next several weeks.

nothingismagick avatar Sep 27 '22 12:09 nothingismagick

Just would like to know if there is any new update? Thanks!~

xeoshow avatar Nov 28 '22 04:11 xeoshow

Closing this because we now are releasing android/ios support in the next branch (2.0.0-alpha).

See this merge: https://github.com/tauri-apps/tauri/pull/5787/commits/df2e027dd97b9cab7cbe350b40bde9bea31d05fe

nothingismagick avatar Dec 09 '22 17:12 nothingismagick

I want to know if there will be some tutorials to write an Android-iOS dual-platform mobile app?

huangjj27 avatar Dec 10 '22 10:12 huangjj27

Yes, we're working on it right now!

nothingismagick avatar Dec 10 '22 10:12 nothingismagick

当我们支持 Android/iOS 时,sidecar 是否会有任何限制?我想知道他们在移动设备上的支持有多容易。

I would like to know if there is any progress on this issue? I currently use sidecar on both iOS and Windows. Will it work on mobile?

kitty-eu-org avatar Mar 07 '24 04:03 kitty-eu-org

我想知道是否有一些编写Android-iOS双平台移动应用程序的教程?

+1

kitty-eu-org avatar Mar 13 '24 02:03 kitty-eu-org