Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
gurman on 9th of june: revamped siri will come with ios 27.2!
gurman on november: revamped siri will come before new year!
gurman on january: revamped siri absolutely comes with ios 27.4!
gurman on april: it will come with 27.5
gurman on may: it will come with 28!!!!! cmon guys!!!
 
  • Like
Reactions: miq
So Apple is already trying to soften the blow from the lack of fixes in iOS 27? That isn't reassuring.
Wrong interpretation.

iOS27 is SW built BY AI. It will have a vast number of bug fixes courtesy of Codex and Claude.

iOS28 will be SW built FOR AI. It will be the first chance to start rethinking how ubiquitous language can reshape the UI. In iOS27 language will still be a second class modality, with the primary goal being to get people to **** about "Siri Sucks". There'll be a small amount of additional language use, but not much more than that.
iOS 28 will be when we start to get real APIs that can track gesturing, that have vision models well integrated with language, and that have screen/camera understanding. So you will be able to point or touch to say things like "What's that building?" or "Can you make the loss numbers in this window red?"

As always with Apple, this will likely lag by six months or so earlier similar attempts by Android, maybe MS, and whatever weirdness OpenAI is cooking up. As always with Apple, it probably won't matter because Apple will be the one that shows everyone else how this stuff *should* work.
 
that make sense. iOS 28 is prepare for the iPhone XX (or 20th anniversary version, you name it). It must be significant
 
Why…? A foldable isnt going to be running 2 instances of the OS, just switching display modes…
iPadOS and iOS have accumulated different APIs etc over the years. Switching display modules if one display runs iOS and the other iPadOS is really switching between two codebases and apps (even though they share 90% of code, they’re different). iPadOS is not just iOS running on a larger display anymore like it was in the past. And even then the apps were often different apps and iOS/ipados never had to share data and states between two apps like that.
 
iPadOS and iOS have accumulated different APIs etc over the years. Switching display modules if one display runs iOS and the other iPadOS is really switching between two codebases and apps (even though they share 90% of code, they’re different). iPadOS is not just iOS running on a larger display anymore like it was in the past. And even then the apps were often different apps and iOS/ipados never had to share data and states between two apps like that.
Please point me to an API difference you think would require “sharing data and states” between multiple instances of an app
 
Please point me to an API difference you think would require “sharing data and states” between multiple instances of an app
Sharing live process memory is not supported in current iOS/iPadOS; How would multiwindow scenes (supported on iPadOS but not iOS) transfer? Third-party apps do not get raw access to the Photos app’s private database. They use PhotoKit / Photos picker, with user permission and limited-library rules. PhotoKit local identifiers are device/library-specific; Apple added PHCloudIdentifier specifically to map the same asset across devices/libraries, which shows that even Apple’s own photo-library model assumes identifier translation, not one universally shared DB handle. So even the photos app can't just share pics between iPadOS and iOS on the same device without some form of adaptation. Photoshop/video renderers would need resumable document/project state: active canvas, undo stack, render queue, GPU/Metal resources, temporary caches. Persisting that cleanly across a display/OS transition is possible, but expensive. Live GPU/renderer state would not simply “move” unless Apple built a system-level handoff mechanism. etc.

Point to any provisions in iOS that support sharing data and states between iOS and iPadOS running on the same device.
 
Sharing live process memory is not supported in current iOS/iPadOS; How would multiwindow scenes (supported on iPadOS but not iOS) transfer? Third-party apps do not get raw access to the Photos app’s private database. They use PhotoKit / Photos picker, with user permission and limited-library rules. PhotoKit local identifiers are device/library-specific; Apple added PHCloudIdentifier specifically to map the same asset across devices/libraries, which shows that even Apple’s own photo-library model assumes identifier translation, not one universally shared DB handle. So even the photos app can't just share pics between iPadOS and iOS on the same device without some form of adaptation. Photoshop/video renderers would need resumable document/project state: active canvas, undo stack, render queue, GPU/Metal resources, temporary caches. Persisting that cleanly across a display/OS transition is possible, but expensive. Live GPU/renderer state would not simply “move” unless Apple built a system-level handoff mechanism. etc.

Point to any provisions in iOS that support sharing data and states between iOS and iPadOS running on the same device.
My dude, we’re not talking about dual os instances… there’s no need… think of this as what happens when you plug in an external screen into an ipad pro and it gives you some more windowing options. Apple isnt going to run 2 full darwin stacks on a folding devices, that would be silly, they’ll expose a subset at least of the additional iPadOS API and let apps shift based on the windowing exposed. I’m legitimately not sure why you think this type of use case needs to run multiple copies of the OS, this is a solved problem
 
My dude, we’re not talking about dual os instances… there’s no need… think of this as what happens when you plug in an external screen into an ipad pro and it gives you some more windowing options. Apple isnt going to run 2 full darwin stacks on a folding devices, that would be silly, they’ll expose a subset at least of the additional iPadOS API and let apps shift based on the windowing exposed. I’m legitimately not sure why you think this type of use case needs to run multiple copies of the OS, this is a solved problem
Sure. Whatever. Go back and read the first post you replied to. I was specifically explaining to someone why using iOS on the outside display and iPadOS on the inside display is not simple without reworking.
 
Sure. Whatever. Go back and read the first post you replied to. I was specifically explaining to someone why using iOS on the outside display and iPadOS on the inside display is not simple without reworking.
Look, they're *the same OS*. They have some different APIs exposed, but they're exactly the same under the hood. MacOS, iOS, tvOS, iPadOS, watchOS, etc are all the same OS.

They're all Darwin/XNU (aka the current version of NextSTEP pretty much) with mostly the same tooling, drivers, and even mostly the same APIs.

There's some differences in APIs exposed, slightly different bootloader config on MacOS, and some differences in what is allowed in userland depending on the device (but, for example, if you jailbreak an iOS machine and drop into a shell you'll be in an environment pretty much identical to macOS, up to an including all the GNU applications, and the ability to run binaries or even install a whole build toolchain).

The naming differences are more about focusing Apple's dev teams and marketing for consumers. Each is a logical seperation, not a different OS in the technical sense. Apple's core OS team is the same for everything.

Shifting what APIs are available based on devices plugged in and active (which is essentially how you handle multiple screens, no matter internal or external) is not hard, and is already done *all the time* on everything from assistive devices to attached auxiliary devices like watches and headphones to network adapters to GPUs, to etc.

Shifting windowing sizing and modes based on displays is already normal on all these devices.

Even, going into userland, services like a browser are built in in places you may not expect - a good example of that is something you can test right now is messaging yourself a link and then clicking it on an aWatch. Safari isnt an available app in the app list, but it's on the device and it will load the webpage. You can browse the web on your watch, albeit it's a pain (I usually use that capability to look up things on wikipedia or quick googles on my watch when I'm not near any other device)

And most popular iOS apps also already have iPad modes too (like, say, the NYT app). Apps that dont still run on iPads but stretched (like Instagram until very recently), they work just fine. MacOS has the full iOS and iPadOS API available too, the only reason not all iOS/iPadOS apps arent available on MacOS is Apple doing some gating with signing to give the developers the choice, that's why when they first enabled iOS apps on macOS you could use iMazing to download any of your apps and fire them up on your mac. They've improved their gating, but the capability isnt limited.

at *worst* Apple would have to run 2 different windowing managers (which is a *long* solved problem, I used to run multiple copies of X on Linux machines like 30 years ago), and there's no real reason for that, I gaurantee they'll either just allow apps to switch to iPad format when a folding device is open or create a new intermediate mode. Apps that dont support switching initially, probably ones that dont have iPad scaled options, will simply get stretched or letterboxed, just as now. Other than that it wont be any different from plugging an external monitor to your macbook and then closing the laptop, it just shifts everything to the only active display.
 
Last edited:
  • Like
Reactions: BSDnostalgia
IMG_4731.jpeg

What is this phone angle about 🤔😂
 
  • Like
Reactions: miq
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.