Re:ARM-Ed Mac: We Have an Answer
by tasogare on Sunday March 22, 2020 @06:11PM
(#22659207)
They sure can’t move ipadOS devs to iPad since XCode is not supported on it.
[ Parent
| on HN ]
Re:ARM-Ed Mac: We Have an Answer
by freehunter on Sunday March 22, 2020 @06:14PM
(#22659229)
That's the case right this minute, but thanks to Apple's famous secrecy, all that could change five minutes from now. Much in the way people say "I'm certain there are ARM-based Macs running inside Apple", I'd be pretty certain that there is at least one iPad running XCode inside of Apple.
Re:ARM-Ed Mac: We Have an Answer
by dreamcompiler on Sunday March 22, 2020 @06:56PM
(#22659539)
Xcode will probably run on iPad soon. I still won't care. As a developer, I need two kinds of freedom: The freedom to choose or build my own language and IDE, and the freedom of my customers to install my software without paying a tax to or needing approval from $FAANG.
Apple has made it quite clear that neither of those is ever going to happen on IOS.
Re:ARM-Ed Mac: We Have an Answer
by imtringued on Monday March 23, 2020 @05:09AM
(#22662274)
The ability to deny these freedoms makes getting rid of Macs so appealing. The potential for vendor lock-in is huge.
And after that you just need iPad ports of all other Mac software that Apple uses internally. What do they use to do their graphics, video, CAD, etc?
XCode or no, I can't imagine doing serious software development without a terminal and all the common *nix utilities.
The year we get Xcode on iPad is likely the same year that we get a general sandboxed terminal / developer environment IMO.
I guess I never done serious development then.
Those toy environments on Amiga, Mac OS, Windows, Symbian, J2ME, Android.
> Mac OS
What are you talking about? You've got basically a complete unix shell available there.
I am talking about Mac OS, not about Mac OS X or macOS.
Ok fair enough. My issue is, whenever a project grows beyond trivial scope, it will usually involve at least some scripting, and likely some tooling, like a process which watches the source files and performs some action when they're updated.
It's very limiting not to have a shell, and arbitrary execution environment, and the wealth of tools which have been created over the years for the *nix environment.
That is part of an IDE feature list.
An IDE is never going to be as flexible as a unix environment. It can deliver some of that, but it's likely you will run into limitations sooner or later.
From the point of view from Xerox PARC workstation experience, which is kind of replicated in modern IDEs, it is the UNIX experience that fails short.
The shell is a subset of what an IDE REPL is capable of, with OS API integration and structured data manipulation.
As for background processes, that is a basic feature of any modern IDE.
That would be something I would expect to be demoed at WWDC 2020.
Now that it isn't happening, lets see how it goes.