Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Plans to Let Developers Release Universal Apps That Work Across iPhone, iPad, and Mac
- Thread starter MacRumors
- Start date
- Sort by reaction score
Exactly. My guess is that the iOS <--> macOS integration will be more of deprecating macOS APIs and less expanding iOS APIs. Since Swift and its build chain are now designed for Linux first, I expect Apple to completely move its iOS and macOS development to Linux in exactly the same way and reason it dropped OSX Servers in its data centers.
macOS has a lot of problems working right or well in professional applications. Apart of UI, Apple is just too far behind in software technology for professional computers. For example they tried for a couple of years to use their own rewritten DNS lookup code in macOS and finally reverted back to BSD code because they never did get it work correctly or reliably. Had they just stuck to macOS's BSD underpinnings things would be a lot better, because there is no better OS than BSD in the data center. But Apple being Apple, had to dumb down macOS just to make it Apple.
Apple does not care about the professional space. Apple really only wants to have a low end device that it can sell to university students and others that need just a little bit more than an iPad can deliver. Can't sell an Apple device to 1/4 of the world population, then forget it. That is the Cook strategy.
Apple makes it really easy for devs so that only what's needed for your platform is downloaded from the store.
I see a few advantages:
- Apps that have mobile companion apps will be able to come all in one purchase (although that will probably be more expensive)
- Maybe more games will come to MacOS? I mean if including MacOS becomes just a bit more effort maybe it will bring more devs on board (iOS is such a powerful force in gaming yet MacOS is irrelevant)
So, the math on this is a little fuzzy, but here is the quote from Schiller:
Schiller said:
The question is what does Apple consider a professional app. From what I've been able to guess, they consider apps like the Adobe Suite, Logic,Xcode, and Final Cut as Pro apps. I think I saw Gruber make some sort of a reference to this definition on a podcast around the time of the roundtable. I don't think they consider Office and the like to be a pro app.
I think if you include Office in your numbers, it goes up. Or, just count people who use the Mac in a professional environment using run of the mill apps.
App slicing in iOS 11 already removes bloat. 32-bit iPhones don't download arm64 code or iPad icons, etc.
Nope. You assume that Apple will support a compromise. They instead might require separate NSWindowControllers for the macOS slice (supports only a mouse based UI), and UIViewControllers for iOS slice (supports only a touch based UI), just like they now require a separate WKInterfaceController for bundled watchOS extensions. Thus, no compromising on the optimal UI for each platform.
If you are a developer, you can do that now with your own apps (or any open source apps). I run lots of my iOS apps in the iOS Simulator on my Mac.
Or the opposite, by forcing developers to design for the best of both worlds (or 4 worlds including watchOS and tvOS) in order to submit to the combined app store.
You assume Apple will allow touch-based UI in the macOS slice of a hypothetical Universal app.
I assume the opposite.
Apple might just allow an ARM iOS app to use a mouse based UI *if* the user connects an external keyboard and mouse to their iPad, and the app also includes both macOS and bitcode support.
Apple won't add touch support to macOS (which is awful ergonomics for iMacs). Instead, they might add mouse support to iPad apps, but only if the iPad app includes both bitcode support and code for a macOS UI (NSViewControllers, etc.). Note that an app built with bitcode allows running that app on either an arm64 or x86-64 CPU (if both UI libraries are available).
A developer can use the lipo command-line tool to build fat (x86 and ARM) executable code now.
Last edited:
I don’t think this will solve the limitations on iOS for example how you mail merge on Microsoft Word and Excel?
Looks like exactly like UWP. The idea is that you share core functionality, but design a custom UI for the OS, however reality is that we end up with with a full "native" version of an app with all features and an "universal" version with limited functionality restricted by the less capable supported device, then spent yeas updating the universal app until it having the original features of the native version. When Microsoft had this idea, T.C said: They are confused, they don't know what to do, and that Apple had a clear path of platform separation.
This is a perfect example (out of MANY) where Microsoft did it first (and VERY POORLY) and Apple imitated and did it right. I have no doubt this will be a great thing for the Apple Ecosystem as it will be very well thought out from a technology and usability standpoint and will be vastly superior to what Microsoft has tried (and FAILED) to do.
Well, the last time there were universal apps (the Intel/Motorola thing), there was bloat, but hopefully now this can be taken care of relatively easily.
They already have, like, 90% of this. The biggest problem with creating universal iOS and Mac Apps is that the APIs you use to create the UI are not as easy to use on macOS (it's natural. Even on iOS, they're starting to accumulate cruft. It's just growing old...).
But everything apart from creating the UI is the same on iOS and macOS. They are already using a "universal" operating system.
So I'd be very interested to hear what exactly they are changing.
But everything apart from creating the UI is the same on iOS and macOS. They are already using a "universal" operating system.
So I'd be very interested to hear what exactly they are changing.
Apple aims to allow developers to release universal apps that work across iPhone, iPad, and Mac as early as next year, according to Bloomberg News.
..and we're off for 50 pages on this thread...
..and we're off for 50 pages on this thread...
Ugh. So now desktop apps will be dumbed down to the level of detail and complexity that can be managed on a phone-sized touchscreen? No thanks. I use a desktop instead of an iPad for a reason.
One term:
Model-View-Controller
https://en.wikipedia.org/wiki/Model–view–controller
And I don't think this means that we'll be seeing Final Cut Pro for the iPad anytime soon. What it DOES mean is that a whole CLASS of Applications that COULD exist and run decently on either Platform can be designed to do just that.
And I don't think it will be done with Fat Binaries; but rather, with JIT Compiling. In other words, you will design your Application in Swift (and/or MAYBE Obj-C), and, upon Launch, the Application will be automatically compiled on-the-fly for the appropriate Platform, and then Run...
That's how they handled the 68k to PPC transition, and it worked VERY well, indeed!
Honestly, there is enough fracture between AppKit and UIKit that just making it possible to use both AppKit and UIKit in a single binary isn't really a great answer. I could technically build "fat" iOS/Mac binaries today in this manner. A proper universal app really should include some level of merging of AppKit and UIKit so I write less code. There's already quite a bit of overlap on what UIKit and AppKit does.
If I have a single-column table view controller, I shouldn't need to write two versions of that controller, like I need to have today. It should just be a UITableView, with something like a UIColumnTableView subclass for multi-column table views that only make sense on iPad and Mac.
Not to mention that ideas like letting iPad use AppKit view controllers if a mouse/keyboard is attached makes the job of developers more annoying than today. Again, I'd much rather see the two frameworks merge if Apple is going to really go down the Universal path. They can always treat macOS as a separate size class for the purposes of layout. (Compact, Regular, Jumbo?)
Which would be nice if UITableViews handled scroll wheel input, or two-finger gestures weren't painfully common on iOS as an input method... Not a terribly great way to get to the realm of "Universal" IMO. Having two silos worked so well for Win 8, they ditched it in the very next major release and called it a feature at the same time.
Probably, but it’s possible Apple didn’t want to overburden/scare away developers during the early years of the App Store, but now realize their mistake with waiting this long and to some degree neglecting the Mac in favor of mobile.
Not sure: don't mac store apps have windowing similar to windows 10 store apps?
[doublepost=1513807926][/doublepost]This looks like an arm Macbook in 1-2 years. Like windows 10 on arm, x86 apps will run in emulation. MacOs will be retained for more powerful platforms (imac, macbook pro, mac pro). Will there be an arm macbook and an ipad pro? Will the 2019 macbook have a touch screen?
I don’t think Apple would be rolling out the iMac Pro and future Mac Pro if the end game is to dumb down macOS. This would be a great way to introduce a modestly priced A series laptop. It would probably sell like hot cakes. Notice how the 11” MacBook Air disappeared leaving a hole in the lineup? This new move would test and prepare people for dealing with iOS apps with or without touch, keyboard, or mouse. The library of apps is already there.
Last edited:
To some degree, you can do this in Xamarin. You write your apps in C# and it translates the code into the proper language for Android, iOS, Windows, and macOS. You just have to set up your libraries and it works. Thats what my father does when he writes his programs for his company.
Which is great, since billions of people have no interest in learning emacs or vi or JCL (et.al.,etc.)
[doublepost=1513809808][/doublepost]
Maybe the complete opposite. iPad apps might have the option to include a UI that is "smarted-up" to the level of a professional workstation app if the user plugs in a keyboard and mouse/trackpad. An iPad has more pixels and more megaflops than an SGI workstation that I used to use.