Mobile development

Any native Android/iOS development ways without using Android Studio/XCode?

I’d prefer not to use different kinds of frameworks from other languages, like Flutter or Kotlin/Multiplatform.

I’m not looking for a Flutter-like Rust framework (will we ever get it?), but for a way just to build my apps without external dependencies (or at least without buying a Macintosh).

1 Like

I don't think that is possible.

The way Apple have done their licensing and distributions, it's not practical to compile for iOS or MacOS with anything other than a Mac host. You won't be able to legally get the system libraries and toolchain your app needs for linking unless you use XCode.

I'm pretty sure there is a way to manually install just the Android SDK/NDK without needing to pull in all of Android Studio. That'll give you system libraries, a compatible version of Clang, and a linker that can be used to create Android executables.

The cargo ndk tool automates a lot of the NDK management and I've found that running cargo ndk build --target armv7-linux-androideabi will almost always Just Work.

Along this lines, is there something similar to Electron, but uses wasm ?

I.e. my ideal mobile dev platform would be something like this:

  1. Android / iOS provides you a wasm runtime; with different hook functions, depending on Android / iOS

  2. You compile Rust to wasm32, using stubs/mocks for the hook functions

It almost sounds like you are describing a Chrome and Safari :wink:

If Chrome/Safari had a "installed webpage" feature which allowed webpage bundles to have "native app" level phone access, it'd be everything I want.

I guess maybe the lack of this feature is on purpose -- i.e. apps are purposely difficult to install so that users are protected from unwittingly installing a malicious app simply by visiting a malicious site and clicking 'ok'

It's not quite "native app" level access because you are still restricted to web APIs, but Progressive Web Apps get pretty close.

Don’t you think you need Tauri?

It's much simpler: Apple wants to be sure no one may give anything to users without their permission. That infamous freedom from porn. 100% of apps are 100% controlled by Apple 100% of time.

How would that “ideal platform” provide that coveted and all-important “freedom from porn”?

If the answer is “it wouldn't” then Apple wouldn't allow it. Plain and simple.

Apple may tolerate some such shenanigans is some apps (especially large and popular ones), but only as you don't bring attention to it and don't change things behind their back too much.

If they would find out that your app gives you the ability to run unrestricted wasm modules and you actually abuse it… it would yank your app and would apologize for the failure to clearly explain to you why your app wasn't supposed to be ever allowed to be on the iPhone in the first place!

P.S. Also note that Apple doesn't allow you to run any JITs. The only whitelisted JITs are in the browsers. This makes it hard to produce fast wasm interpreter (although wasm3 is not too shabby, but again, if Apple would think you are abusing it your app would be banned).

I think it's in the in-app-purchase cut. Otherwise, how would you explain Google having the same policy on Android ?

Android doesn't have the same restrictions on the technical details of how apps operate. Firefox for Android ships the actual gecko engine iirc, while the iOS app is basically just a wrapper around a system web view

Not to be pedantic, but pragmatically speaking, how does this affect the developer experience ?

In both Android, iOS, the setup seems to be:

  1. use their custom IDE
  2. write an app
  3. submit app
  4. pray for 'yes' from an opaque process with little recourse if 'no'
  5. give up 30% of revenue (world's most expensive CDN on a per-byte basis?)

I mean it's a pretty big deal that you literally can't use a browser engine other than WebKit on iOS

The developer experience is not great in either case of course, I don't disagree with you there.

1 Like

On Android this part is completely inverted: you submit the app and are assumed to act in good faith. If you would be found in violation of rules then they can always ban you later.

And the same with updates: there are no review which may stop you from putting update in the Google Play. There are certain checks, though (e.g. today you wouldn't be able to upload ARM32-only app).

There very few technical limitations in Google Play. You app runs in a sandbox but there are no requirement to avoid sideloading of the new content, etc.

This makes perfect sense if you combine it with previous item: why erect the walls if the main road is always free-to-enter?

All the limitation of non-technical form are similar if not identical, but that's less of a developer problem and more of the management problem (except when you are the sole developer and act as your own manager, too).

You can always skip that part and distribute your app directly from your web site. Epic does that with Fortnite.

It's no different from how macOS, Windows or Ubuntu act: on all these platforms you can either jump through hoops and deliver apps via “official” store or decide that you don't need helper and deliver apps directly to the end user.

Only iOS is different. Even if you want to make app and run it's on your own device you need to get permission from Apple.

1 Like

Ah, is the situation the following? (I wasn't even aware of browser engine limitations.)

iOS: Safari / Webkit, "Chrome" / Webkit, "Firefox" / Webkit

Android: Chrome / Blink, Firefox / Gecko, Safari / Webkit

Yes, in addition to the aforementioned JIT limitations the App Store guidelines explicitly forbid usage of other browser engines

2.5.6 Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript.

All "web browsers" on iOS are essentially a WebKit web view with some features tacked on.

1 Like

Not all. Safari have special permissions and additional features which only it may do.

Apple doesn't try that to differentiate it, though: usually new features first appear in Safari and then, shortly, become available for other browsers, too.

But sometimes, for a short time after release of new iPhone with new features, only Safari supports them.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.