Federico Viticci:
Apple listened to feedback about Stage Manager and – at least so far – implemented the key improvements I wanted to see. I’ve been using Stage Manager on my iPad Pro since yesterday afternoon, and I even tested it on a portable external display that I brought with me for this trip. If this early, limited experience is of any indication, I think I’m going to be happy with Apple’s revised version of Stage Manager for iPad by the end of the summer. But then again, caution is necessary given how last year’s beta evolved over time.
[…]
Based on what I’ve seen so far, Stage Manager for iPad is still based on different size classes for apps, which means that when you resize a window, you’re effectively choosing from a list of invisible presets that control how small or big a window can be and how its contents are laid out. However, compared to iPadOS 16, it feels to me as if the process of resizing a window is smoother and more lenient than before. You still see a window “blink” as it gets resized, but I’m under the impression that there are more “intermediate steps” when it comes to the sizes you can choose from. I understand why resizing an iPad app cannot be as pixel-precise as resizing a Mac one, but as long as Apple figures out a system to make layouts more flexible given the limitations of iPadOS, I’m good with that.
There’s even better news on the window placement front: unlike the original Stage Manager, you can now almost freely place windows anywhere and make them overlap as much as you want if necessary. The “almost” part is necessary since I believe there is still a rail-based system underneath Stage Manager, but in iPadOS 17, it’s like those rails have gotten way denser than iPadOS 16, giving you a lot more options for placing a window somewhere and making it stay there.
Previously:
Update (2023-06-23): Federico Viticci:
Stage Manager for iPadOS 17 also comes with a new ‘fast app pairing’ feature.
This is a new multitouch-based option to quickly pair an app with another app/set of apps.
Just hold down on a window, then tap apps in the dock or the left strip to quickly pair them with the app you’re holding.
Update (2023-07-26): Steve Troughton-Smith:
To say Stage Manager is ‘fixed’ in iOS 17 is to say the Butterfly Keyboard was ‘fixed’ in its first revision. They’ve patched it to make it just a little more tolerable (which should have shipped last year) but it still has all the fundamental problems it had in iPadOS 16. It’s still an alt-mode only available on some iPads, it conflicts with all the existing iPad UX, it has no APIs so apps can adapt better to it, and I still expect it to be abandoned and replaced with a do-over in a few years.
If you could imagine the bare minimum that could have been done to fix Stage Manager in iPadOS 16, this is less than that.
Federico Viticci:
I was pleased to see I’m not the only one who’s liking the new Stage Manager for iPadOS 17. Similarly, I’m not alone in thinking Apple should continue refining the iPad’s multitasking system and catching up with macOS.
Update (2023-08-30): Steve Troughton-Smith:
I have gone through iPadOS 17, and all my old posts about iPadOS 16, and collated a list of many of the things Stage Manager still gets wrong 👀 There’s definitely more to add, but this is why the two tiny changes to Stage Manager this year (tiling, and shift-clicking) don’t impress me.
The major change between Stage Manager now and this time last year is just how buggy and broken it was then. So much time was spent fixing its performance, but not design.
iOS Multitasking iPadOS iPadOS 17 Stage Manager
Juli Clover (Slashdot, Hacker News):
Apple’s developer betas have historically been limited to developers who have a paid account that costs $99 per year, but with the launch of the most recent betas, that’s changing.
Anyone can now enroll in the free version of the Apple Developer program and get access to beta releases. All that’s required to download betas is an Apple ID.
I don’t see how this now differs from the public beta, which also required signing in.
Howard Oakley:
With the annual resurgence of interest in running macOS betas, this article considers how you can run a developer or public beta-release of macOS on an Apple silicon Mac.
[…]
Now, that Mac has to be connected using the Apple ID registered with the beta programme; for developer betas, that’s the Apple ID by which you’re recognised as a developer. You should then be able to opt for Beta Updates in Software Update, in System Settings > General. Click on the Info tool on that line, and select the beta you want to install. You can also use that to connect using an Apple ID specifically for betas.
I ran into trouble when I instead signed into my Mac as a whole using my developer Apple ID.
Running macOS in a lightweight virtual machine (VM) on Apple silicon is free, simple, and performs at close to native speeds. Although it has some significant limitations, notably no iCloud access and App Store apps (and others depending on your Apple ID) can’t run in the VM[…]
Previously:
Update (2023-06-09): Craig Hockenberry:
So what’s the trick to get the macOS Sonoma .ipsw to install in UTM running on Apple Silicon?
[…]
The trick is to install Xcode (and all it’s dependencies) before you try to use the .ipsw with the Virtualization.framework.
Howard Oakley:
Lightweight VMs can run current and previous macOS, but not future macOS, which requires newer frameworks. I will explain fully in an article.
Update (2023-06-16): Howard Oakley:
Worse: with the exception of Numbers/Pages/Keynote, even free 3rd party apps from the App Store can’t be run. It’s almost like Apple doesn’t want us to use App Store apps.
Updating to the latest beta, I again ran into the problem where there was no visible way to sign into beta updates with my developer Apple ID. The trick is to use this Terminal command (via mikeymikey):
open 'x-apple.systempreferences:com.apple.Software-Update-Settings.extension?action=showBetaUpdates'
Update (2023-06-21): Howard Oakley:
macOS VM guests running on Apple silicon deliver excellent performance and broad support for a range of standard devices. At present their main limitations are:
- no control over Machine ID hence serial number;
- NAT networking;
- no Apple ID or iCloud access;
- almost no App Store apps can be run;
- limited support for peripheral devices.
Apple ID Esoteric Preferences Mac macOS 14 Sonoma macOS Beta Software Update Virtualization
Mysk:
“Over a month of standby”
This is how Apple used to market the iPad’s battery. Today, the iPad runs several background processes while in standby. My HomeKit experiment clearly shows that. I achieved 20 days of standby on my iPad Pro. Without disabling Home the battery would have died after a week.
I doubt I would even get a week on my iPad Air. If I don’t leave it plugged in, it’s always dead when I reach for it.
It’s not great with my Kindle, either, unless I put it in Airplane Mode. Then the battery life is amazing.
For iPad, I think the available settings don’t really match how I use it. I don’t want to turn off Background App Refresh because then apps will be out-of-date when I’m actively using it. But I don’t want them constantly doing stuff when the iPad is “off,” either. I think what I’d like is for it to automatically go into Airplane Mode when I turn off the screen.
Previously:
Update (2023-12-11): Christian Selig:
iPad feature I’d love: Deep Sleep. I find whenever I go a few days or a week between using an iPad, it’s often dead or almost dead. An auto-deep sleep mode after 24 hours of non-use would be awesome, even if it took 5 seconds or so to wake back up.
Update (2024-10-24): Christian Selig:
iPad feature request: auto “deep sleep” after 24h idle (10 seconds to wake is okay). iPads used to last over 30 days on standby, but every time I pick one up now after less than a week it’s dead.
Sam Rowlands:
Likewise Apple used to promote that MacBooks would last a month on standby, nowadays 14 days seems to be the average.
Battery Life iOS Multitasking iPad iPadOS iPadOS 16 Kindle Wi-Fi
James Dempsey:
The idea of being able to adopt upcoming changes sooner rather than later is a good one. However, adding an ever-increasing number of separate compiler flags for each upcoming feature does not scale well.
To address this, Swift evolution proposal SE-0362, implemented in Swift 5.8, details a generalized mechanism for enabling upcoming features.
[…]
SE-0362 also introduces a new hasFeature() compilation condition that checks whether a feature is enabled. This allows you to write code that uses a feature if present or uses alternate code if not present.
Previously:
Language Design Programming Swift Programming Language
