Video: https://vimeo.com/585335551
https://developer.apple.com/app-store/review/guidelines/#sof...
""" 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps. Educational apps designed to teach, develop, or allow students to test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the app completely viewable and editable by the user.
"""
This is not native, this is just not-Electron (or Xamarin or whatever else).
What libraries that native code uses is a different issue - but it's still native code.
People build up an intuition about how apps on their devices work, going non-native is an easy way to subtly break their expectations.
I don’t really know what makes an app “native.” React Native apps are considered “native” because they are using the native UI toolkit. (C++) Qt apps are native because they are “native code,” and compile down to machine code with native binaries for their platform.
Web is distinctly not native because it’s a different runtime abstracted from the underlying OS. Electron introduces wrinkles in the distinction since they put the abstraction layers into the application package. React Native does that and then also introduces the idea of “native” meaning native widgets.
But what is the native UI toolkit? Win32 has a controls system, but even many Microsoft apps built into the OS don’t use it… so if your app does the same thing the built-in OS does, and uses say, WinUI or what have you, it’s hard to argue it’s “non-native.” Likewise for Linux. There’s no actually standard UI toolkit in any given Linux desktop setup.
MacOS and iOS largely stand alone as the platform where the “native UI” distinction stands strong, but I do think Flutter challenges it a bit on iOS, if at a high cost.
This all to say, I think the word “native” is surprisingly unclear.
Native on mobile is very easy to define because both major mobile platforms have extremely opinionated development kits that include a "blessed" method of making apps.
“First party UI toolkit” is a phrase that imparts some bias because it implies, in the frame of this discussion, that this is what makes a UI “native.” But even though that would be a workable criteria, it does have one serious problem: it’s utterly meaningless to the end user. It doesn’t imply almost anything about the user experience or the integration with the OS. It doesn’t really imply a whole lot to the developer anymore either.
Compare this to the Linux desktop ecosystem, and it’s hard to tell much of a difference (other than the obvious fact that the Linux desktop is terrible :) — the UI toolkits feel similarly disjointed. Nothing feels “specifically” native. The only frame of reference is what your DE happens to use.
Obviously, this all comes down to philosophy and I don’t mean to imply that this makes Windows worse except for in the more obvious ways (conflicting design language, look’n’feel, developer experience.) After all, even though I still believe macOS is ahead in this regard, I loathe to use macOS.
Apple's rules are what Apple says they are on a given Tuesday.
They can (and do) allow apps that flagrantly violate the guidelines, as well as refuse apps seemingly based on the direction of the prevailing wind, and unless you have an internal contact at Apple to protest, you're stuffed.
Developers can do whatever they like with Xcode installed, but good luck distributing anything like this reliably.
Nice toy, but I wouldn't bet a business on it.