I think if this happens it will only support new tech. SwiftUI over interface builder and no cocoapods. It might even drop standard Xcode project files and only support Swift package manager. I think it would largely be driven by needs in education, but also be of interest to pure swift developers that want to iteratively develop on a real iPad instead of a simulator. I think a design goal would be to significantly lower the barrier to entry over Xcode. I love Xcode, but there is a lot to learn before your first line of code.
With SwiftUI, swift package manager finally supporting iOS libraries, and a proper keyboard this also feels like the right time for this to happen.
It’ll happen. The iPad Pro is 100% capable now to host real pro apps.
Xcode isn't a "pro" app. It's a developer tool.
I think Prosser and plenty of other non-developers have conflated "building for iOS" and "building for ARM", and I'd be willing to bet that's what's going on here. Especially with Prosser's language. "present on iOS".
Present? That's a weird way to put it. Present on ARM builds of macOS reads better.
Prosser has this odd habit of saying he's not entirely sure about something and then saying he's absolutely certain of that thing in the next sentence, and then taking credit for being first. All while saying he's just an entertainment site. He doesn't understand the deeper issues and he covers that by apparently assuming there's no depth to it at all.
As for developer tools, Apple has already been enhancing Playgrounds on iPad at a pretty good clip so far, and if they're going to host developer tools on iPad OS they'll likely come at it with a large contribution from that side and meet in the middle, at some space in between Playgrounds and current Xcode.
Development is not just a lone person sitting in front of a machine writing code, even when it's just a lone person sitting in front of a machine writing code. There's testing and integration and often a lot of these things are automated to some extent. And that's only some of what the developers in this article are talking about.
Xcode is not nearly so needed by developers as interface builder and swift UI. The rest will be a bit slower or cumbersome to use. Xcode on iPad has been requested for years.
when visiting a client, the ability to create a quick UI or to make a change quickly is what developers need to present to clients. And the ability to sit in ‘the comfy chair’ and sketch out some UI aspects and flow would be really nice. I have a wishlist ready for when it happens.
the other thing needed is something simple in a graphics editor, fireworks for iPad would have been perfect. PNG with vector data embedded and layers. Simple vector tools. PNG and SVG for export formats, and the ability to export every size needed by apps.
It’ll happen. The iPad Pro is 100% capable now to host real pro apps.
"Real pro apps" have been capable and available on the iPad since it debuted.
What's not great is trying to run Xcode on a small display. I know this because it's not great (it's only OK) on a 13" MacBook Pro either, but if we include external displays into the equation the iPad can be a decent way for developing apps and it might be a lower cost development machine than an iMac for those who already have a peripherals, assuming a non-Pro iPad can be used.
Hopefully they also find a way to make Xcode better on iPadOS for use with a small multitouch display over what is available on macOS. For instance, perhaps they will use swipe gestures so you can quickly access and hide the Navigator, Utility, Debug, Editor, and Interface Builder areas without them all always being on screen and without negatively affecting the workflow.
This. When we consider that iPads and iPhones are appliance computing devices, with very small screens, it becomes apparent why building apps on them has been low-priority.
If we get it, I'm not certain that it will have feature-parity. I think it may be reduced in capability, or unable to support every random workflow & toolset, especially considering the more restrictive, sandboxed nature of iPadOS. I wouldn't expect any & everything from desktop Xcode projects to just work. But even if it doesn't work for every possible Xcode project and build configuration, I don't think that's a deal breaker. If it works for non-customized workflows, that's a start. Maybe down the road new iPad-Xcode-compatible modules can become a thing.
Remember the outrage when Apple removed iWork suite features so they could make the features across all their OSes work the same way. They can't do that for Xcode, but the could make it more like iMovie for iOS v iMovie for macOS in terms of functionality. Does anyone here prefer to use iMovie on their iPhone over their Mac? I would expect the feature parity for iPadOS would be significantly better than the app exampleI used, but there will still probably be some missing features that will upset people, especially those that are still upset that the iPad isn't running macOS.
"Assuming that's true, it's impossible that Apple wouldn't already have Xcode running on ARM —and Final Cut Pro X, too. Porting to the ARM processors in an iPad would need more work, but the size of that original conversion job can't be estimated, and it has surely been done already. "
This is a bad assumption.
The 'original conversion' is the easiest part. Not that it's 'easy', but it's the job of the compiler to do this part. Sure, there will be issues at this point, but again, easiest relative to the rest of the process. When you're taking a macOS app and moving it whole cloth to iPadOS, you're refitting it to a different substrate. Even Apple *ported* the entire iPadOS substrate to macOS to make Catalyst work. Yes, there's an "iPadOSOnMacOS" framework that exists so that Catalyst can do what it does.
It's best not to think much at all about the ARM switchover as contributing much to Mac Applications moving to iPadOS. A far bigger contributor is Apple making the underlying frameworks like Metal and Foundation and URLSession and the like have identical or nearly identical APIs regardless of which OS they're on. They've been doing this for years now. And SwiftUI is their answer to providing feature parity (such as it is) to the UI framework.
Xcode is not nearly so needed by developers as interface builder and swift UI. The rest will be a bit slower or cumbersome to use. Xcode on iPad has been requested for years.
when visiting a client, the ability to create a quick UI or to make a change quickly is what developers need to present to clients. And the ability to sit in ‘the comfy chair’ and sketch out some UI aspects and flow would be really nice. I have a wishlist ready for when it happens.
Interface Builder is within Xcode. And SwiftUI is a code framework that has a specific editor within Xcode. There's no distinction between Xcode and these things.
And there's NO WAY anyone's doing significant "quick UI" when presenting to clients. Sorry, that's not how it works. Rough sketches are exactly what's right for UI mechanics. Designers spend much longer putting together coherent, cogent presentations to clients and take client wishes into account and go back to the offices to incorporate those.
I would be really happy to have Xcode on an iPad. Like another poster here said, it’s pretty much the only reason I use my Mac.
I have to disagree with the developer in the article saying how things like command line access is necessary for development. It is necessary for some development, entirely dependent on how the developer setup their project. I’ve been doing development (professionally) for 20 years and the only times I’ve had to use the command line were with certain projects that used 3rd party libraries (which I already dislike...) that needed download and/or compilation via the command line. I’ve never started a project that needs that and I never plan to—3rd party libraries die out and make things far more difficult to update when they do.
This is unrealistic for many, many, MANY classes of apps. Your experience is not universal.
"Assuming that's true, it's impossible that Apple wouldn't already have Xcode running on ARM —and Final Cut Pro X, too. Porting to the ARM processors in an iPad would need more work, but the size of that original conversion job can't be estimated, and it has surely been done already. "
This is a bad assumption.
The 'original conversion' is the easiest part. Not that it's 'easy', but it's the job of the compiler to do this part. Sure, there will be issues at this point, but again, easiest relative to the rest of the process. When you're taking a macOS app and moving it whole cloth to iPadOS, you're refitting it to a different substrate. Even Apple *ported* the entire iPadOS substrate to macOS to make Catalyst work. Yes, there's an "iPadOSOnMacOS" framework that exists so that Catalyst can do what it does.
It's best not to think much at all about the ARM switchover as contributing much to Mac Applications moving to iPadOS. A far bigger contributor is Apple making the underlying frameworks like Metal and Foundation and URLSession and the like have identical or nearly identical APIs regardless of which OS they're on. They've been doing this for years now. And SwiftUI is their answer to providing feature parity (such as it is) to the UI framework.
So what's the point of Catalyst then since it sounds like SwiftUI is the future for their platforms?
It’ll happen. The iPad Pro is 100% capable now to host real pro apps.
"Real pro apps" have been capable and available on the iPad since it debuted.
What's not great is trying to run Xcode on a small display. I know this because it's not great (it's only OK) on a 13" MacBook Pro either, but if we include external displays into the equation the iPad can be a decent way for developing apps and it might be a lower cost development machine than an iMac for those who already have a peripherals, assuming a non-Pro iPad can be used.
Hopefully they also find a way to make Xcode better on iPadOS for use with a small multitouch display over what is available on macOS. For instance, perhaps they will use swipe gestures so you can quickly access and hide the Navigator, Utility, Debug, Editor, and Interface Builder areas without them all always being on screen and without negatively affecting the workflow.
This. When we consider that iPads and iPhones are appliance computing devices, with very small screens, it becomes apparent why building apps on them has been low-priority.
If we get it, I'm not certain that it will have feature-parity. I think it may be reduced in capability, or unable to support every random workflow & toolset, especially considering the more restrictive, sandboxed nature of iPadOS. I wouldn't expect any & everything from desktop Xcode projects to just work. But even if it doesn't work for every possible Xcode project and build configuration, I don't think that's a deal breaker. If it works for non-customized workflows, that's a start. Maybe down the road new iPad-Xcode-compatible modules can become a thing.
Remember the outrage when Apple removed iWork suite features so they could make the features across all their OSes work the same way. They can't do that for Xcode, but the could make it more like iMovie for iOS v iMovie for macOS in terms of functionality. Does anyone here prefer to use iMovie on their iPhone over their Mac? I would expect the feature parity for iPadOS would be significantly better than the app exampleI used, but there will still probably be some missing features that will upset people, especially those that are still upset that the iPad isn't running macOS.
Dev tools are meta-apps in a big way, and so these kinds of comparisons don't apply. Feature parity across platforms is only preferred when content is king. There's no clear separation between file contents, projects, data and executables in a given project, to say nothing of flipping the whole notion of "access one store from multiple locations" into distributed repos' notion of "accessing the same location from multiple stores"
Perhaps we can look to the much simpler problem of adding an cursor, trackpad nd mouse to an iPad (and iPhone). Apple simply, didn’t exhibit any interest in this since the beginning, at least publicly. Then they gave us a primitive c]version in Accessibility. They watched the responses.
NO. They provided Accessible input to those who had difficulty with direct touch input to the screen. Period.
“Yeah, but your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should.”
Why?
Other than to prove it's possible, it's impractical. Why get a high end iPad Pro with an expensive keyboard to use Xcode when Apple already has a powerful computer line it's been refining for decades? Let's break this down logically.
Xcode on iPad wold be impractical without a keyboard. So the iPad config would basally resemble a laptop form factor.
At 13.3", the smallest Mac display is primarily for consumer use. The largest iPad is 12.9". Many of us developers have our windows split into several smaller code panels with inspectors, file browsers, debuggers, terminals, etc.
Oh yeah, as stated in the article: Terminals and command line tools. Would we be forced to use GUI git tools rather than the CLI? They mentioned CocoaPods, there's also yarn/npm. Good luck with that.
A key part of Xcode is the iOS Simulator. Good luck with that.
If you want to develop for iOS, WatchOS, iPadOS, or the Mac, use a Mac. I love the MacBook Air, especially the most recent update. But how about trim its bezels like the 16" MBP and slim it down to the MacBook? Rather than killing the MacBook, Apple should've just added a second TB/USB-C port, used the current Air's processor, and killed the Air. There's your ultra-light, ultra-portable development workstation.
"Assuming that's true, it's impossible that Apple wouldn't already have Xcode running on ARM —and Final Cut Pro X, too. Porting to the ARM processors in an iPad would need more work, but the size of that original conversion job can't be estimated, and it has surely been done already. "
This is a bad assumption.
The 'original conversion' is the easiest part. Not that it's 'easy', but it's the job of the compiler to do this part. Sure, there will be issues at this point, but again, easiest relative to the rest of the process. When you're taking a macOS app and moving it whole cloth to iPadOS, you're refitting it to a different substrate. Even Apple *ported* the entire iPadOS substrate to macOS to make Catalyst work. Yes, there's an "iPadOSOnMacOS" framework that exists so that Catalyst can do what it does.
It's best not to think much at all about the ARM switchover as contributing much to Mac Applications moving to iPadOS. A far bigger contributor is Apple making the underlying frameworks like Metal and Foundation and URLSession and the like have identical or nearly identical APIs regardless of which OS they're on. They've been doing this for years now. And SwiftUI is their answer to providing feature parity (such as it is) to the UI framework.
So what's the point of Catalyst then since it sounds like SwiftUI is the future for their platforms?
It serves a different purpose. SwiftUI is for building new and targeting multiple Apple platforms with the same controls. Catalyst is for getting an iPad app on Mac. If building new ideally it’s better to use SwiftUI.
Perhaps we can look to the much simpler problem of adding an cursor, trackpad nd mouse to an iPad (and iPhone). Apple simply, didn’t exhibit any interest in this since the beginning, at least publicly. Then they gave us a primitive c]version in Accessibility. They watched the responses.
NO. They provided Accessible input to those who had difficulty with direct touch input to the screen. Period.
What an incredibly benighted attitude.
So dramatic, rolleyes. No, what Mel is saying is the pointer functionality evolved. And it’s reasonable to expect other technology will start simpler and evolve. It’s a perfectly reasonable musing.
I would be really happy to have Xcode on an iPad. Like another poster here said, it’s pretty much the only reason I use my Mac.
I have to disagree with the developer in the article saying how things like command line access is necessary for development. It is necessary for some development, entirely dependent on how the developer setup their project. I’ve been doing development (professionally) for 20 years and the only times I’ve had to use the command line were with certain projects that used 3rd party libraries (which I already dislike...) that needed download and/or compilation via the command line. I’ve never started a project that needs that and I never plan to—3rd party libraries die out and make things far more difficult to update when they do.
Well, iPad OS/iOS is in fact a UNIX OS, so theoretically Apple could release Terminal with the developer tools package. I actually wouldn't be surprised if they did.
I do iOS dev work daily. This (Xcode) is not something I need or care about at all running on an iPad.
I could see it be useful in the same way Swift Playground is useful and it could be a next step for that. A way to continue learning and practicing what you learn, etc. I don’t see it currently being that useful at the pro level.
I think a new “Xcode for beginners” for people who have been starting out with Swift Playgrounds, and now wanting to take their first step towards building their first apps, would be great on the iPad. I think focus will be on students.
Full blown Xcode with command tools etc? Yeah... I could see it happening down the line.. But still sandboxed.. I guess?
So we asked developers, both large and
small, both US and globally, what they thought of FCPX coming to the
iPad -- and, more importantly, whether Xcode on iOS is coming [to the iPad]
This is not the first time Appleinsider has been confused over which OS runs on iPads.
Apple discontinued iOS on iPads for a reason. This story likely illustrates one of them.
I think a new “Xcode for beginners” for people who have been starting out with Swift Playgrounds, and now wanting to take their first step towards building their first apps, would be great on the iPad. I think focus will be on students.
Full blown Xcode with command tools etc? Yeah... I could see it happening down the line.. But still sandboxed.. I guess?
Yeh, a while back I went to the Apple Store for one of their courses on Swift hoping I could use it for something productive -- like pulling my data out of the black hole of the HealthApp. But, I was told I had to buy a Mac to even try something like that.
It's good to see the iPad growing up and, to paraphrase an old Army recruitment ad, "becoming all it can be".
Comments
With SwiftUI, swift package manager finally supporting iOS libraries, and a proper keyboard this also feels like the right time for this to happen.
I think Prosser and plenty of other non-developers have conflated "building for iOS" and "building for ARM", and I'd be willing to bet that's what's going on here. Especially with Prosser's language. "present on iOS".
Present? That's a weird way to put it. Present on ARM builds of macOS reads better.
Prosser has this odd habit of saying he's not entirely sure about something and then saying he's absolutely certain of that thing in the next sentence, and then taking credit for being first. All while saying he's just an entertainment site. He doesn't understand the deeper issues and he covers that by apparently assuming there's no depth to it at all.
As for developer tools, Apple has already been enhancing Playgrounds on iPad at a pretty good clip so far, and if they're going to host developer tools on iPad OS they'll likely come at it with a large contribution from that side and meet in the middle, at some space in between Playgrounds and current Xcode.
Development is not just a lone person sitting in front of a machine writing code, even when it's just a lone person sitting in front of a machine writing code. There's testing and integration and often a lot of these things are automated to some extent. And that's only some of what the developers in this article are talking about.
when visiting a client, the ability to create a quick UI or to make a change quickly is what developers need to present to clients. And the ability to sit in ‘the comfy chair’ and sketch out some UI aspects and flow would be really nice. I have a wishlist ready for when it happens.
the other thing needed is something simple in a graphics editor, fireworks for iPad would have been perfect. PNG with vector data embedded and layers. Simple vector tools. PNG and SVG for export formats, and the ability to export every size needed by apps.
This is a bad assumption.
The 'original conversion' is the easiest part. Not that it's 'easy', but it's the job of the compiler to do this part. Sure, there will be issues at this point, but again, easiest relative to the rest of the process. When you're taking a macOS app and moving it whole cloth to iPadOS, you're refitting it to a different substrate. Even Apple *ported* the entire iPadOS substrate to macOS to make Catalyst work. Yes, there's an "iPadOSOnMacOS" framework that exists so that Catalyst can do what it does.
Interface Builder is within Xcode. And SwiftUI is a code framework that has a specific editor within Xcode. There's no distinction between Xcode and these things.
And there's NO WAY anyone's doing significant "quick UI" when presenting to clients. Sorry, that's not how it works. Rough sketches are exactly what's right for UI mechanics. Designers spend much longer putting together coherent, cogent presentations to clients and take client wishes into account and go back to the offices to incorporate those.
This is unrealistic for many, many, MANY classes of apps. Your experience is not universal.
Dev tools are meta-apps in a big way, and so these kinds of comparisons don't apply. Feature parity across platforms is only preferred when content is king. There's no clear separation between file contents, projects, data and executables in a given project, to say nothing of flipping the whole notion of "access one store from multiple locations" into distributed repos' notion of "accessing the same location from multiple stores"
So dramatic, rolleyes. No, what Mel is saying is the pointer functionality evolved. And it’s reasonable to expect other technology will start simpler and evolve. It’s a perfectly reasonable musing.