There is no way XCode is coming to the iPhone. Or, if it did, who would use it? The UX isn’t great on a 13” laptop, so studding that into a tiny screen would be crazy. The iPad option is cool though.
There's more to Xcode than the UI.
I think what this really means is that it will now be possible to compile code on iDevices.
Note that compiling code is not just something that software developers do when they are writing apps.
Compiling code on the fly in response to input makes for better, more flexible apps (especially think AI/ML).
But it also makes for a much greater security risk.
So the issues in play here are security vs features/flexibility.
Bottom line --- this has almost nothing to do with UI, it has almost nothing to do with people doing software development on an iPhone.
Excellent point. As did the article, the first thing we think of when we hear "XCode" is the IDE, but it's a constellation of tools. Perhaps some of those are what's "present" in iOS 14.
I think it would meet the definition of hazing to assign Apple staff to rewrite XCode IDE (including Interface Builder!) to work on a phone (small screen, no keyboard, no mouse, etc.).
If there is an iPad version of Xcode, I would expect it to be SwiftUI-only, with updates to SwiftUI announced alongside it. Objective-C might be possible, but I doubt they would do it. Interface Builder involves too much separate chrome with the visual delegate connections and so on.
If there's an iPhone version which can be used to write and compile code locally on the device, I would be shocked if it supported anything besides Swift and SwiftUI.
I can see an Xcode implementation for iPhones. It's not going to be a multi-pane application, but it will be a one-pane at a time app, functional enough to do checks and small mods. For iPad, well, it's taking Apple a very long time to do something they should have done like 5 years ago.
There are still things to do on the hardware front, such as 8, 16, and 32 GB RAM options, and external display support.
Xcode should have been on iPads 5 years ago? I don’t think so. Not if you’re living in this universe...they are just now getting to the point where it’s feasible, they definitely weren’t half a decade ago. And if you’re saying “Well they should have been!” then what can I say, you’re not being rational. I should have been a millionaire five years ago too.
It was feasible 6 to 7 years ago let alone 5. The first iPad Pro 12.9 was shipped in November of 2015, about 4.5 years ago, and that hardware was more than capable, just needed more RAM. RAM is still a problem as Apple has strangely only increased the amount of RAM in iPad Pros from 4 GB to 6 GB across those 4.5 years. This will be the biggest gating factor for Apple to bring Xcode, FCPX, LPX over or for Adobe to bring the full featured versions of Photoshop, Illustrator, etc over.
Yes, this by definition is a "what should have been". Not sure how rationality applies here as I'm specifically disagreeing with Apple's chosen development path for the iPad when I say they should have done something different in the past. That's entirely rationale, and something everyone of us does. There's nothing that can be done about it now other than complaining, but entirely rationale to say Apple should have done something different, just like it is entirely rationale to say Apple messed up the Mac Pro for 5 years, and should have done something different, something faster to address the issues with 2013 Mac Pro.
No, because you're conveniently ignoring everything that had to happen, sequentially, to get to this point in time. It's as if you believe they've held off on these things purely out of spite, rather than engineering. It's like taking Windows 10 and saying, "This is what Windows Vista should have been!" Is it better? Yes. Should an older version have been the better version? No, because you had to get to this point by getting to this point.
As for the MP, as they discussed in great detail in the TechCrunch article, they discovered the thermal limitations of the cylinder only once it became clear the industry was not moving in the parallel processing direction they had anticipated. The "thermal corner" they found themselves painted into. And from there it took time to realize it, accept it, and go back to the drawing board with an entirely new engineering perspective. They started from scratch and created an exceptional modular solution. Apple products take years to develop. And now we have the course correction. But they couldn't have created this if they didn't create that first...linear time is funny like that. Likewise for the iPad -- 5 years ago iPadOS didn't exist, drag & drop on it didn't exist, and trackpad optimization didn't exist. Nothing was ready and I don't know anyone who reasonably expected Xcode on the iPad of half a decade ago.
This would be a boon for developers creating apps that involve GPS, as it would be relatively easy to get and test with live GPS signals, when developing outdoors on an iPad.
Yes and apps for AR/Lidar and ones that use the cameras. It would be much easier to develop on the device while being able to pick it up and debug it. Some IDEs have real-time feedback and having to compile on another platform and send the entire build to the device for testing isn't the fastest workflow. iPads also have external display support:
It just needs for apps to be able to use the full display like some Apple apps do and they can do that with Xcode.
Some developers won't own a Mac at all but want to develop for iOS. Having a compiler on iOS allows them to develop on any platform and compile on the devices. Some of the new generation of developers will use an iPad as their main device and want to develop for the iPhone, building on the iPad and deploying to the iPhone should be perfectly feasible.
My first thought was that the idea of doing programming on an iPhone is dumb.
My second thought was that I could see some cowboy programmer doing a quick fix to existing code during a cab ride to the airport.
My third thought was that such “on the go” modifications would probably break more code than they fixed.
Professional software development has processes to accommodate this. Live software sometimes needs emergency patches for critical issues. These have reproducible conditions and the developer can supply a quick fix, which then goes through testing phases before deployment. Not many types of software need critical patches but security vulnerabilities qualify.
Suffice to say, the more capability iOS can offer the better. There's no technical reason an iOS device can't do everything a Mac OS device can, they just don't all need to. It doesn't make sense for a software developer to develop an entire app on an iPhone. It does however, make sense for a UI designer to mockup and test an iPhone UI in Xcode on their commute and be able to drop it into an app when they get to work or to be able to debug camera capabilities when out in the field or to debug how an app handles different mobile connections.
Some developers won't own a Mac at all but want to develop for iOS. Having a compiler on iOS allows them to develop on any platform and compile on the devices.
Even working on a 13" Mac notebook with a mouse pointer is difficult with Xcode so I don't know how creating IOS apps on an iPhone could possibly seem feasible to you. On iPadOS, maybe, but only with use of a mouse/trackpad and physical keyboard, and likely with a connected display, especially with the smaller iPads, unless you have a new paradigm in mind for the app, which seems like something Apple—being Apple—would want to do.
This will absolutely not work on iOS!
If you honestly think that iOS apps should be made on an iPhone, an iPadOS app be made on the iPad, do you also believe that a tvOS app be made on the Apple TV and a watchOS app be made on the Apple Watch. Personally, I think that sounds ridiculous as building apps on the iPhone.
I can see an Xcode implementation for iPhones. It's not going to be a multi-pane application, but it will be a one-pane at a time app, functional enough to do checks and small mods. For iPad, well, it's taking Apple a very long time to do something they should have done like 5 years ago.
There are still things to do on the hardware front, such as 8, 16, and 32 GB RAM options, and external display support.
Xcode should have been on iPads 5 years ago? I don’t think so. Not if you’re living in this universe...they are just now getting to the point where it’s feasible, they definitely weren’t half a decade ago. And if you’re saying “Well they should have been!” then what can I say, you’re not being rational. I should have been a millionaire five years ago too.
Agree and iPad should have had a dedicate OS branch 5 years ago to make the distinction.
As an iOS developer I would be thrilled to have Xcode on my iPad 11/12.9... however having 25 years of experience with Apple development and tools if I had to put money on it I'd say it'll be a gimped version that will exclude any serious iOS development (more like Playground on steroids)... part of it is Xcode can have some heavy RAM requirements that would increase if running under ARM (though that may not be a show stopper).
Some more complicated workflows may not be possible, and of course if you're developing connected apps (like what I do... which connect with BLE devices) and you want to debug, that may be out of scope.
Still it's a start and would be happy to see a move in that direction... I'd also be thrilled to be proven completely wrong and they announce a full iOS Xcode that let's you do whatever you can do in Xcode on macOS.
WWDC (virtual) isn't too far off... my iPad + Magic Keyboard (expensive, but awesome) is waiting to create some code!
Interesting, will a potential 'Mac simulator' in Xcode for iOS be the first part of ARM macOS publicly released? I can't say I'd ever consider using an iPhone/iPad for coding unless it's simply an extension of the app running on a Mac but I guess it could pull developers in who don't want to have to buy a Mac.
Well, this would fall into line with Apple wanting to move their Macs to custom ARM processors. They would need an Xcode that runs on ARM. So, if Xcode runs on ARM, why not iPad?
I think it's a great idea, but today's Xcode is quite resource intensive. So, either they are going to revamp a lot of the code / build / debug cycle to be more resource efficient or it's only going to run on very beefed up iPads (a lot internal RAM and fast internal storage).
This is mistaking the OS for the chip architecture (once again).
This would be a boon for developers creating apps that involve GPS, as it would be relatively easy to get and test with live GPS signals, when developing outdoors on an iPad.
yeh maybe, although you can remote debug on the iPhone, or iPad. Of course switching networks in those circumstances can be a pain.
At the moment there is a lot of filesystem access involved with Xcode, especially for what you may think are simple tasks, like font instalment or linking frameworks that aren't built in.
Until recently - the advent of the swift package manager - you needed terminal chops, or access to the Finder, to install any third party software and I can't see anybody doing anything on the iPad with React Native, and Flutter etc, all of which need fairly significant downloads and access to the OS.
That said this could be a ploy by Apple to reduce the number of people using 3rd party frameworks.
I'm very interested to see how Apple pulls this off.
I started programming in BASIC almost 40 years ago on pocket computers with very limited screen real estate and rudimentary toolset (to say the least). Between then and now and through many high level languages and platforms my constant desire has always been to obtain more and more screen real estate through every means possible, including larger individual screens, multiple screens, more larger screens, using iPads as auxiliary screens, eye numbing tiny font settings, etc. A lot of this constant need for even more screen real estate was driven by a constant increase in the number of auxiliary IDE windows and information density that became essential for both development (writing and managing code), monitoring/tracing, and debugging. As the number of auxiliary windows and information density increased the space left over for code editing windows got smaller and smaller, only increasing the need for even more screen real estate. Not to be left behind in the feature bloat department, code editing windows got increasingly more complex and feature rich with multiple tabs, split panes within tabs, a ton of contextual information overlaid on top of the text, like syntax coloring and highlighting, auto completion hints, error indications, deeper context menus, etc., putting even more demand of more screen space.
Now we're talking stuffing all, or some subset of that, into an iPhone? I'll be the optimist and say, "bring it on." If Apple can pull this off and the net result is something that is intuitive, productive, and useful to a broader population of professional and enthusiast developers who have hit the wall on trying to accommodate the constantly increasing demands of modern IDEs like XCode, Visual Studio, and Eclipse - I'll be more than impressed.
Anything that can be done to make software development more accessible to a broader group of people will be a benefit for society as a whole. Having the ability to navigate the complexity of a modern IDE and unforgiving languages like C++ and Objective-C (and to a lesser degree Swift, C#, and Java) is certainly commendable in a Spartan punching-bark-off-of-trees sort of way, but it's also a huge exercise in rewarding claptrap and complexity and sustaining misguided priorities. At some point, which probably occurred about 20 years ago or more, developers started to serve the tools rather than the tools serving the developers. It's time to flip the script and hopefully Apple can show us the way.
Software never gets easier, if there is some ease up in complexity in language A vs B, for instance memory management, then language A will also bring in some other complex requirements. Swift looks easy to begin with but the complexity ramps up. And Javascript or Java takes over everything in the end. The end.
Well, this would fall into line with Apple wanting to move their Macs to custom ARM processors. They would need an Xcode that runs on ARM. So, if Xcode runs on ARM, why not iPad?
I think it's a great idea, but today's Xcode is quite resource intensive. So, either they are going to revamp a lot of the code / build / debug cycle to be more resource efficient or it's only going to run on very beefed up iPads (a lot internal RAM and fast internal storage).
The iPad Pro handles 4k video better than my beefed up iMac 27" 4.2 Ghz 32GB Ram.
Also, this update was needed but weak. The keyboard needed to be upgraded. No wifi 6 is puzzling. Was going to upgrade but will wait for next year.
Comments
If there's an iPhone version which can be used to write and compile code locally on the device, I would be shocked if it supported anything besides Swift and SwiftUI.
As for the MP, as they discussed in great detail in the TechCrunch article, they discovered the thermal limitations of the cylinder only once it became clear the industry was not moving in the parallel processing direction they had anticipated. The "thermal corner" they found themselves painted into. And from there it took time to realize it, accept it, and go back to the drawing board with an entirely new engineering perspective. They started from scratch and created an exceptional modular solution. Apple products take years to develop. And now we have the course correction. But they couldn't have created this if they didn't create that first...linear time is funny like that. Likewise for the iPad -- 5 years ago iPadOS didn't exist, drag & drop on it didn't exist, and trackpad optimization didn't exist. Nothing was ready and I don't know anyone who reasonably expected Xcode on the iPad of half a decade ago.
LOL another one. No, it was not possible to add Xcode to the iPad of 10 years ago. Get. Real.
It just needs for apps to be able to use the full display like some Apple apps do and they can do that with Xcode.
Some developers won't own a Mac at all but want to develop for iOS. Having a compiler on iOS allows them to develop on any platform and compile on the devices. Some of the new generation of developers will use an iPad as their main device and want to develop for the iPhone, building on the iPad and deploying to the iPhone should be perfectly feasible. Professional software development has processes to accommodate this. Live software sometimes needs emergency patches for critical issues. These have reproducible conditions and the developer can supply a quick fix, which then goes through testing phases before deployment. Not many types of software need critical patches but security vulnerabilities qualify.
Suffice to say, the more capability iOS can offer the better. There's no technical reason an iOS device can't do everything a Mac OS device can, they just don't all need to. It doesn't make sense for a software developer to develop an entire app on an iPhone. It does however, make sense for a UI designer to mockup and test an iPhone UI in Xcode on their commute and be able to drop it into an app when they get to work or to be able to debug camera capabilities when out in the field or to debug how an app handles different mobile connections.
This will absolutely not work on iOS!
If you honestly think that iOS apps should be made on an iPhone, an iPadOS app be made on the iPad, do you also believe that a tvOS app be made on the Apple TV and a watchOS app be made on the Apple Watch. Personally, I think that sounds ridiculous as building apps on the iPhone.
Some more complicated workflows may not be possible, and of course if you're developing connected apps (like what I do... which connect with BLE devices) and you want to debug, that may be out of scope.
Still it's a start and would be happy to see a move in that direction... I'd also be thrilled to be proven completely wrong and they announce a full iOS Xcode that let's you do whatever you can do in Xcode on macOS.
WWDC (virtual) isn't too far off... my iPad + Magic Keyboard (expensive, but awesome) is waiting to create some code!
yeh maybe, although you can remote debug on the iPhone, or iPad. Of course switching networks in those circumstances can be a pain.
At the moment there is a lot of filesystem access involved with Xcode, especially for what you may think are simple tasks, like font instalment or linking frameworks that aren't built in.
Until recently - the advent of the swift package manager - you needed terminal chops, or access to the Finder, to install any third party software and I can't see anybody doing anything on the iPad with React Native, and Flutter etc, all of which need fairly significant downloads and access to the OS.
That said this could be a ploy by Apple to reduce the number of people using 3rd party frameworks.
Software never gets easier, if there is some ease up in complexity in language A vs B, for instance memory management, then language A will also bring in some other complex requirements. Swift looks easy to begin with but the complexity ramps up. And Javascript or Java takes over everything in the end. The end.
Also, this update was needed but weak. The keyboard needed to be upgraded. No wifi 6 is puzzling. Was going to upgrade but will wait for next year.