The post gives an specific technical limitation for why Nova wouldn't be possible due to iOS apps store policies. So they wouldn't be able to make a subscription version even if they wanted to?
> The biggest technical hurdle is the inability to run external processes on iOS and iPadOS. There’s just no way around it: this is required for modern web development. For example, the TypeScript extension is one of the most popular Nova extensions right now, and it launches and runs the TypeScript compiler. While we could attempt to build the TypeScript compiler into Nova, we can’t possibly anticipate and include every such tool that might be needed by a developer. We’d need to bundle compilers, interpreters, and language servers for just about every programming language in existence, not to mention tools like linters, JavaScript transpilers, and bundlers. The scope would quickly become unmanageable, and we’d always be lagging behind the latest versions of these tools.
> and the fact that they refuse to allow other browser engines on iOS is the reason why we can't have nice things like progressive web apps.
Is that against the App Store guidelines? Or is that a programming limitation? I am aware all the iOS browsers are just a wrapper around WKWebView but am curious why another engine can't be implemented.
> The biggest technical hurdle is the inability to run external processes on iOS and iPadOS.
> Apps on iOS and iPadOS must use Apple’s Javascript interpreter, JavaScriptCore.
Both of these really suck because they are policy, not technical, decisions. Even setting aside the arguments of whether JIT code is a security concern (it is not unless your security model is one where codesigning exists to prevent the addition of new native code) that you cannot spawn a new process, nor can you ship another JavaScript interpreter, is really unfortunate.
Allowing apps to spawn new processes is easy (I mean, just inherit sandboxing rules and resource limits…) and allows for a lot of new usecases, like robust crash reporting, web servers, privilege separation, and more. That Apple allows this on macOS and even uses it for its own apps on iOS just shows how useful this can be and how little it affects the security model of iOS.
Likewise, not allowing other JavaScript interpreters is just…annoying. Regardless of your opinions of JavaScriptCore, this is an unfair limitation on an already slanted playing field. Coupled with the fact that the JavaScriptCore interpreter (which the framework uses for anything you run in-process) is literally designed for low resource consumption instead of than performance makes this even more infuriating.
> That complaint doesn't quite make sense to me because things like "language servers for every programming language in existence" don't exist iOS in the first place, even if you were allowed to run external processes.
Yes, they do exist for iOS, they're the existing language servers. iOS is Unix on ARM, it can run most of (all of?) the Node ecosystem (including the existing LSP implementations) just fine. The problem is Apple doesn’t provide the APIs to run them, and bans apps that create their own workarounds to run them (unless they’re in the app bundle, which my understanding is allowed, e.g., that’s how something like play.js works https://playdotjs.com/).
> Likewise, not allowing other JavaScript interpreters is just…annoying. Regardless of your opinions of JavaScriptCore, this is an unfair limitation on an already slanted playing field.
Reading the actual policies reveals that other interpreters are in fact allowed, but they may only be used for code that is part of the app bundle.
The actual limitation is that apps must be self-contained, and only javascriptcore and webkit may be used to run code from an external source (e.g. downloaded or user input).
> An iPad is fine for writing code, but not capable of compiling/running code.
I mean, hardware-wise, it's totally capable; it's got a pretty powerful CPU in it. It's just the App Store publishing policies that don't want to cooperate.
But there's nothing fundamentally stopping someone from creating a Crouton-like "chroot in a box" environment and publishing it as an XCode project; and nothing stopping you from taking said XCode project and deploying it to your iPad using development provisioning.
> So now are kernel extensions also “applications”?
They're things some "applications" need in order to function, so if you can't include them you've effectively prohibited those applications.
But what does it matter if something is an "application" or not? Why is it any better if Apple precludes third parties from competing with their kernel extensions?
> VSCode is written in Typescript. It is an Electron app.
It's not the IDE you have to be able to run, it's the code you write in it.
> And Microsoft already has a solution to run .Net code on iOS
That's just compiling the code to a native binary, which you would then have to go submit through Apple's store. How does that help for an IDE expected to allow you to test (i.e. execute) and debug the code you've just written ten seconds ago?
> Can you name any none pay to win games that couldn’t be a subscription service outside of the App Store?
We can see right there some examples of what isn't allowed:
Not facilitate real-time, person-to-person services (e.g., providing tutoring services, medical consultations, real estate tours, or fitness training).
Apps that let people access digital content such as music or video, but not as the primary functionality, are not considered reader apps and are not eligible for the External Link Account Entitlement. For example, a social networking app that lets people stream audiovisual content is not eligible.
> And your solution to supporting CUDA is a breakout box on an iPad with an nvidua card? Who the hell is going to buy that?
Presumably the same sort of people who buy the existing graphics card docks on the market for other platforms.
IIRC there's a policy against running downloaded code (at least automatically downloaded code) in anything but the bundled JS runtime, but bundling an interpreter in an application and running user-provided code is not an issue. You can run a Python app on iOS (e.g. via Kivy) and there are Python interpreters in the appstore.
> I was planning on taking on porting Emacs to the iPad
I thought that was impossible anyway, given Apple's prohibitions on both GPL code and software runtimes in iOS apps? However I suppose Emacs could be sideloaded onto jailbroken iPads.
>First, the iPad has to be powerful enough to do fast compilations etc.
It already is, and has been for a while. The iPad Pro is faster than the MacBook Air and is approaching the MacBook Pro.
>How are you going to use Xcode when you don't have Finder
Files.app++
>a terminal with a compiler
When I mean Xcode, I mean the whole package with LLVM, Bash, Brew and a Terminal emulator. Apple is already allowing “programming environments”[1] in the App Store. I can see a Dev Mode that allows you to fork and do all the things we are used to.
Would you be happier if I said "excluding software that competes with their own"?
Why would it be any better if they are excluding hardware that competes with their own?
> Apple never stopped VSCode from being on iOS. There are plenty of IDEs for the iPad built by third parties.
VSCode is an app that needs the .NET runtime, in order to run the code you write in e.g. C#. They don't allow the runtime it needs which means they don't allow the app (which competes with theirs).
> Are you making up things now? You don’t run CUDA on any non Nvidia hardware.
iPads have Thunderbolt, so you could actually plug NVIDIA hardware into them. Or someone could port CUDA to Apple's GPUs, as AMD essentially did with HIP. Except that would be this:
> But yes, you are free to port OpenCL to iOS if you want to.
Implementing such a thing efficiently requires driver support, but you can't modify the drivers nor supply your own.
> A “payment API” is not an “application”. Yes the cross platform frameworks do expose the underlying API.
A payments system is a part of an application. They prohibit broad categories of apps that use any but their own payments system.
Using Apple's payments API doesn't allow for apps that use a competing payments system, which was the whole point.
> And you can have a cross platform app that forces you to subscribe outside of the App Store - Spotify, Netflix, Microsoft, etc all do that.
I point to a category of thing they prohibit and then you point to the exception that proves the rule as if that meant they don't impose the rule.
We know they don't do it for a specific subset of subscription services anymore. They still do it in general, which is to say that they still do it.
> Are you saying that their no competitors on iOS to AppleTV, Apple Music, Apple Podcasts, Apple Books, the iWork suite?
This is the same thing again. It's not a question of if they prohibit every app that competes with theirs, it's a question of if they prohibit any app that competes with theirs.
>On the other side, having a full blown IDE for creating and locally running iOS applications would be a huge step forward.
Are you aware of iOS Dev environments such as Pythonista? It’s even possible to take a Pythonista app, copy it into an XCode template and release it on the App Store, though of course that has to go via a Mac.
> and not being able to use an app that allows me to create iOS apps
Maybe you already know about this and you just mean there isn't an app that provides the equivalent of your full MacOS dev environment, but you can absolutely build and run iOS apps on your iPad with Swift Playgrounds.
It has a lot of shortcomings, but I've used it to create a couple little personal apps that I can run without distributing them through the App Store.
> that iOS apps only have two wide-distribution models: paid, with Apple, on the App Store, or open-source and, by that nature, free.
Please correct me if I'm wrong but I don't think that's true. Just because it's open source doesn't mean it's free, it just means that technical users could, if wanted, compile it from source. But, especially with iOS apps, this is not even true since you do need to have a developer license and a Mac to be able to compile and run it on an actual iPhone.
So in reality, while this is open source, only developers who pay Apple, are able to install this application, even if it's open source.
> The biggest technical hurdle is the inability to run external processes on iOS and iPadOS. There’s just no way around it: this is required for modern web development. For example, the TypeScript extension is one of the most popular Nova extensions right now, and it launches and runs the TypeScript compiler. While we could attempt to build the TypeScript compiler into Nova, we can’t possibly anticipate and include every such tool that might be needed by a developer. We’d need to bundle compilers, interpreters, and language servers for just about every programming language in existence, not to mention tools like linters, JavaScript transpilers, and bundlers. The scope would quickly become unmanageable, and we’d always be lagging behind the latest versions of these tools.
reply