Monday, September 16, 2019 [Tweets] [Favorites]
Tip: If you use the rename refactoring in Xcode a lot, you can save some time by skipping the code folding animation:
defaults write com.apple.dt.Xcode CodeFoldingAnimationSpeed -int 0
I’ve tended to do it manually with Find/Replace, both because the animation was so annoying and because the refactoring would often fail with an error or not actually find all the occurrences. With this default and Xcode 11, I’m going to start trying it again.
Previously:
Have you ever wondered where your Mac’s macOS wallpaper was taken? Sure, we know roughly where, but do you want to know exactly where those iconic shots were captured? YouTuber Andrew Levitt apparently did. So he set about tracking down the location of each macOS wallpaper along with photographer Taylor Gray and videographer Jacob Phillips.
The result is a 13-minute video showing their escapades as they attempted to recreate the images we’ve been seeing on Mac desktops for years.
The video is here.
Allan Odgaard (via David Heinemeier Hansson, Hacker News):
After far too long, there is no longer any qualifier suffix in the version string, so it is now finally just “TextMate 2.0”
[…]
Not everything on the wishlist made it into 2.0, but TextMate remains a work in progress, so don’t despair :)
Congratulations are definitely in order after so many years of development. It is apparently a free update. There are tons of changes listed, but unfortunately they aren’t (yet?) organized in a way that’s very helpful for those who haven’t been using the app and following along with its development. In any case, it’s great to see continued development of native Mac text editors.
Allan had been making very fast progress on TextMate for the first several years, and the community was full of excited “early adopter” types, who were very chatty and supportive, and were actively engaged in improving the TextMate language “bundles”, trying out new features, etc. I found the ##textmate IRC channel at the time to be the best place to get technical help with pretty much any programming language.
Then at some point Allan decided that he had made some suboptimal design choices in pretty much every component of TextMate 1, and wanted to improve those with new designs. But he thought it would take more work to incrementally swap new parts in that were compatible with all of the other stuff he wanted to eventually replace, so he started in on what was a substantial rewrite of everything.
That (a) took away his incremental improvement of TextMate 1, (b) took his time away from being as responsive to user questions/ideas, (c) caused bundle authors to slow down on improvements to TM1 bundles while they waited to see what new features TM 2 had in store.
At the same time, the creation of an “insider” IRC channel took away some of the activity from the main IRC chat, the migration from one big SVN repository to a bunch of separate per-language Git repositories damped a lot of the bundle development activity as people were no longer exposed to every change to every bundle, so the bundles didn’t cross-pollinate as much.
Previously:
The steps for automating notarization involve running the “altool” command from Terminal. Everything in the guide linked above should work perfectly unless you’re a member of more than one development team. If you have more than one team associated with your Apple ID, the back-end at Apple doesn’t know which one it should notarize on behalf of.
[…]
All that said, here is a surefire list of steps for obtaining your ITC Provider ID, or as it’s described in the altool man page, your ASC Provider Shortcode.
- Create a new App-Specific Password from your Apple ID management page.
- From Terminal, invoke iTMSTransporter with the following options:
xcrun iTMSTransporter -m provider -u <yourAppleID> -p <yourAppSpecificPassword>- At your discretion, revoke the App-Specific Password you created for this process.
It seems to be my name concatenated with the old “person number” for my developer account.
See also: Notarizing Your Flash/Air Applications For macOS (tweet).
Previously:
We’re not informed about when these updates occur, nor of their purpose, nor do we know what changes they bring. In the past, Apple’s security tools used to refer to malware using names which, although not always the best-known, at least enabled us to know what they protected us from. Then last year Apple switched to using internal code names, so we now know that the latest MRT update enables that tool to remove MACOS.87fabeb and MACOS.07758e9. Oh boogaloo.
If you went to your physician and they said that you needed an immunisation but refused to tell you what it protected you from, would you consider that informed consent? Surely, everyone would be suspicious and refuse.
[…]
I keep trying to imagine who Apple thinks it’s protecting by this prolonged silence and refusal to inform. It’s not the malware developers, who will quickly be able to tell the effect of any changes that Apple makes to the protection in macOS. It’s not the users, who are unable to make informed decisions about whether third-party protection is worthwhile. It’s not system administrators, who are as baffled as anyone else on the receiving end.
Friday, September 13, 2019 [Tweets] [Favorites]
Firebase Crashlytics installs its own font?
Crashlytics will only install the font for users who have registered to install pre-release apps via the Beta by Crashlytics product. The font includes a unique identifier that allows us to determine that a crash has come from an app distributed via our Beta product.
Turns out custom fonts can be abused for tracking users.
Yes, that is why Safari is not allowing user installed font access, and the new iOS 13 font installation feature always require user consent to access any user install font.
John Gruber (tweet):
Most users, I suspect, would just allow this, thinking fonts are harmless — but at least those of you reading this are forewarned.
Given that the App Center team was already very familiar with PLCrashReporter, and that they had expressed interest in contributing their changes upstream, it seemed like a natural fit for Microsoft to take over as stewards of PLCrashReporter. To that end, we talked it over and they have graciously agreed to take on responsibility of the PLCrashReporter repository and related sites. To be clear, the licensing of PLCrashReporter isn’t changing, and Microsoft looks forward to working with the community on this open source project.
It’s been said that Microsoft’s core competency is developer tools.
Previously:
Apple today announced a new billing grace period for subscriptions, which will let subscribers who experience unsuccessful auto-renewals continue to use an app’s paid content while Apple attempts to collect payment.
This is a feature that developers can opt into.
What about the opposite problem?!
I would like a grace period when a subscription I forget I even had renews automatically. Even a single day-long grace period would suffice where you can cancel and get a refund on an unwanted periodic subscription.
Previously:
Last year, Apple rolled out the option to pay monthly for some of its two (in some cases three) year AppleCare+ plans for iPhone, iPad, and Apple Watch. Today, Apple quietly changed how it works so customers can buy an indefinite monthly AppleCare+ subscription.
[…]
This sounds like customers can choose to continue the monthly AppleCare+ coverage as long as they’d like or until Apple can’t service the device anymore.
[…]
It’s also good to keep in mind that compared to the normal two-year terms (three years for Apple Watch Hermés and Edition), Apple charges more for the monthly subscription compared to the upfront price. For example, two years of coverage for the iPhone 11 or XR will run $191 if paid monthly versus $149 upfront.
Unfortunately, this doesn’t seem to be available for Macs, where it would be an even better fit—both because AppleCare for Macs costs more up-front and also because Macs will likely be in service for more years.
Previously:
One of the understated components of Apple’s iPhone 11 and iPhone 11 Pro is the new U1 chip. It didn’t get a prominent callout onstage at today’s announcement event, but it will underpin what Apple says are “amazing new capabilities” coming to iOS devices in the future, including a more accurate, directional version of AirDrop coming with iOS 13.
The “U” in the U1 chip relates to the Ultra-Wide Band Radio Technology (UWB) technology it uses. UWB can be used for many application and use cases. One use case that will become very large for Apple as they move to AR/MR technology and Apple Glasses is to be able to track spatial relationships of objects. One way to do this is using lasers and IR systems, and Apple is already doing this to some degree with FaceID and Animoji. The other way to do this is via the radio spectrum.
The Apple U1 Chip most assuredly uses a variant of the IEEE 802.15 WPAN from the IEEE 802.15.4z Enhanced Impulse Radio group of which Apple is an active member. IEEE 802.15.4z to put in simple terms wants to absorb, in some ways, and extend Bluetooth, NFC, WiFi and other network standards and protocols.
The early concept of this technology was used in an all but abandoned Apple initiative called iBeacons [2]. This technology was centered around Bluetooth and Bluetooth Low Energy (BLE). The idea was sound, however the technology was low resolution, so low that it would be hard to be with-in a few feet without triangularization of 3 or more iBeacons and even then it can drift significantly with heat and obstacle issues.
[…]
I feel rather strongly the Apple U1 Chip, over time will be seen as one of the most important aspect of the September 10th, 2019 Apple Event. We will see it as the start of the HyperLocal world of computing that ultimately will lead to less of a need for the cloud.
Previously:
Developers have come to accept that, without warning, Apple can make their work obsolete by announcing a new app or feature that uses or incorporates their ideas. Some apps have simply buckled under the pressure, in some cases shutting down. They generally don’t sue Apple because of the difficulty and expense in fighting the tech giant—and the consequences they might face from being dependent on the platform.
The imbalance of power between Apple and the apps on its platform could turn into a rare chink in the company’s armor as regulators and lawmakers put the dominance of big technology companies under an antitrust microscope.
The thrust of the Post’s story is clear from its headline. But I don’t think it holds any water. What’s the alternative? For Apple never to add any features to the OS that exist in third-party apps?
[…]
When Apple implements a feature or app idea, they do it in a way that has the broadest possible appeal (or at least try to). The key to competing with Apple as a third-party developer is to focus on segments of the audience that want more than the basics.
[…]
The debate over what’s fair game for Apple (or Google, or Microsoft) to copy from third-party developers has nothing to do with app stores. A popular app is a popular app, and the platform vendors have always known all the popular apps.
Every developer is, in a sense, worried about being Sherlocked. But I don’t think this is anywhere near the top of their list for what to change about the App Store. And, as Gruber says, it’s not clear what the solution would be, anyway. That said, I think app stores do change things a bit, in that the platform vendor can get better data sooner, without having to rely on indirect tactics.
Previously:
Thursday, September 12, 2019 [Tweets] [Favorites]
This article will go over how to restore BridgeOS on your T2 Mac. This is not something that you will ever normally have to do. Restoring or reinstalling BridgeOS would only be needed in the following situations.
- 1. Failed macOS Upgrade
- 2. Failed macOS Combo or Delta Update
- 3. Failed macOS Security Update
- 4. Failed macOS Reinstall
- 5. Command Option R fails to boot your T2 Mac to the current version of macOS Recovery. (10.14 is out but the Mac boots to 10.13)
[…]
I tested the BridgeOS restore on multiple Macs for this article. One of my test devices failed in fantastic fashion. What I thought happened was the BridgeOS update just failed on a fluke. What really happened was Apple Configurator 2 attempted to downgrade BridgeOS from Catalina’s version down to the Production version of Mojave. When Apple Configurator 2 attempted to downgrade on the 3rd step it failed leaving the Mac in a Unusable state. Apple straight up does not allow downgrading BridgeOS. I still have my Air that does not boot.
So if you can’t downgrade, and Apple Configurator won’t let you restore the current (beta) version, I guess you’re just out of luck if you need to do this after installing a macOS beta.
See also: Howard Oakley.
Previously:
Ovid (via Hacker News):
By now, many of you have seen the Perl 6 Github issue “Perl” in the name “Perl 6" is confusing and irritating. The issue suggested renaming Perl 6. While some may think that the name of the issue is trolling, or offensive, the actual issue was created by Elizabeth (Liz) Mattijsen, one of the core Perl 6 developers, a long-time Perl 5 developer, and with her spouse, Wendy, has long been an enthusiastic support of Perl 5/6. There is no trolling here. There is a lot of deep thought, careful discussion, and a genuine desire to find a way to bypass some deeply divisive issues in the Perl community.
While the proposed name was “camelia”, Damian Conway made a strong argument in favor of “raku” and it appears the community is leaning towards this name for various reasons.
[…]
The far, far too terse backstory: the Perl 6 community seems to be split between those who view Perl 6 as a sister language to Perl 5 and those who view Perl 6 as a successor to Perl 5.
The Perl 5 community, meanwhile, is split between “f*ck yeah” and “f*ck you”.
Previously:
Python Software Foundation (Hacker News):
We have decided that January 1, 2020, will be the day that we sunset Python 2. That means that we will not improve it anymore after that day, even if someone finds a security problem in it. You should upgrade to Python 3 as soon as you can.
[…]
We did not want to hurt the people using Python 2. So, in 2008, we announced that we would sunset Python 2 in 2015, and asked people to upgrade before then. Some did, but many did not. So, in 2014, we extended that sunset till 2020.
It’s been a long transition because the initial releases of 3.x were rough, broke a lot of code, and didn’t seem to offer compelling reasons to upgrade. Even if you wanted to upgrade, your code might have dependencies that hadn’t yet. So it kind of followed the path of Perl 6, even though it was a much less ambitious update.
Contrast this with Swift, where there’s a little breakage each year, which people complain about, but most active code (unfortunately not most code posted on the Web) does get updated rather quickly. Granted, Swift had the benefit of a smaller and younger installed base.
If you need to get fixes for Python 2, there’s Tauthon (via Hacker News):
Tauthon is a backwards-compatible fork of the Python 2.7.16 interpreter with new syntax, builtins, and libraries backported from Python 3.x. Python code and C-extensions targeting Python 2.7 or below are expected to run unmodified on Tauthon and produce the same output.
Victor Stinner (via Hacker News):
Python 3.0 was released 10 years ago. It’s time to look back: analyze the migration from Python 2 to Python 3, see the progress we made on the language, list bugs by cannot be fixed in Python 2 because of the backward compatibility, and discuss if it’s time or not to bury Python 2.
Let me translate this: filenames, command line arguments, and so on are no longer portable abstractions. They fundamentally mean different things on Unix and on Windows. On Windows, they are ‘Unicode’ (actually UTF-16) and may include characters not representable as single bytes, while on Unix they are and remain bytes and may include any byte value or sequence except 0. These are two incompatible types, especially once people start encoding non-ASCII filenames or command line arguments on Unix and want their programs to understand the decoded forms in Unicode.
[…]
I’ll note that Python 2 is not magically better than Python 3 here. It’s just that Python 2 chose to implicitly prioritize Unix over Windows by deciding that filenames, command line arguments, and so on were bytestrings instead of Unicode strings. I rather suspect that this caused Windows people using Python a certain amount of heartburn; we probably just didn’t hear as much from them for various reasons.
Python Software Foundation (via Hacker News):
“Python’s batteries are leaking,” said Brown. She thinks that some bugs in the standard library will never be fixed. And even when bugs are fixed, PyPI libraries like Twisted cannot assume they run on the latest Python, so they must preserve their bug workarounds forever.
[…]
Brown identified new standard library features that were “too little, too late,” leaving users to depend on backports to use those features in Python 2. For example,
socket.sendmsgwas added only recently, meaning Twisted must ship its own C extension to usesendmsgin Python 2. Although Python 2 is nearly at its end of life, this only holds for the core developers, according to Brown, and for users, Red Hat and other distributors will keep Python 2 alive “until the goddam end of time.”[…]
Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Python 2 and it is difficult to abandon them.
Anthony Shaw (via Hacker News):
One of the features proposed for CPython 3.8 is PEP554, the implementation of sub-interpreters and an API with a new interpreters module in the standard library.
This enables creating multiple interpreters, from Python within a single process. Another change for Python 3.8 is that interpreters will all have individual GILs[…]
Previously:
Wednesday, September 11, 2019 [Tweets] [Favorites]
Amazon e-mailed to tell us that Transmit 5 can no longer support Amazon Drive. Our sincere apologies to anyone using Transmit to access that service. As a heads up, we’ll be removing it very soon — most likely in Transmit 5.6.1.
(We’d have said something sooner but Amazon gave us just 19 days notice! 19 days to update Transmit, and QA test the changes, and update Panic Sync, and QA test those changes, and update the website, and update the screenshots, and update the video, and update the docs, and…)
And to be clear: this is just Amazon Drive, their cloud storage, Dropbox-like service. This will not affect Amazon S3 in any way!
I wonder whether it will still work with Arq.
I, myself, cannot believe Amazon would change their terms and suddenly discontinue service.
Previously:
Apple announced a lot of dates today. Here’s a rundown of all the dates mentioned in the keynote[…]
iOS/iPadOS 13 features coming “later this fall” (not Sept. 30th)
- AirPods audio sharing
- HomeKit Secure Video & routers
- iCloud Drive folder sharing
- HomePod/AirPlay 2 in scenes & automations
- Image Capture API
- Screen Time communication limits
- Announce Messages w/ Siri
This split iOS/iPadOS release could get a bit messy. For example:
- If you upgrade to iOS 13 (iPhone) and switch Reminders to the new format, it’ll stop syncing with iOS 12 (iPad)
- Shortcuts: if you modify an existing one on iOS 13, it’ll break the format on 12
Code found in the golden master version of Xcode 11 confirms that Apple is working on an augmented reality headset of some kind, and perhaps planned to announce it at the event but scrapped the debut last minute.
9to5Mac’s Guilherme Rambo and developer Steve Troughton-Smith found that Xcode 11 features an ARDisplayDevice framework with references to codenamed Apple headsets that are in development, including Franc, Luck, and Garta (which pertains to HoloKit, a third-party device).
The fact that ARDisplayDevice is in the iOS 13 public SDK (check the headers in Xcode!), not a private framework, makes it very clear that this head-mounted ARKit UX was supposed to launch in the iOS 13 timeframe. With iOS 13’s delays, very easy to see how that could get punted
Axel Kee notes a very rough edge in the Xcode 11 GM, which looks like it could have used some more time to bake.
Previously:
Background used to be a good app. You can tell from its early reviews that its users genuinely enjoyed browsing and making use of its hand-curated selection of iPhone wallpapers. In fact, its reviews are generally positive up until late June, when an update began causing some issues. From that point on it becomes clear that Background is no longer owned or updated by its original developer. It’s been flipped.
[…]
The gold standard seems to be a 3-day trial that moves into a $9.99/week subscription, but there’s flexibility here, depending on precisely how evil you want to be. Make sure to hide these new payment options from your pre-acquisition users. After all, you don’t want them updating their glowing past reviews. Oh, and for those new users you’re about to acquire? Make sure it’s darn near impossible for them to find the “x” to close your subscription view (or, for fun, make it completely nonfunctional!).
At this point we must believe they aren’t willing to make the hard judgement call of scam vs not. Which, I should point out, is the entire point of a walled garden. There’s just no other explanation.
[…]
What violation?
Hint: they are violating none except for overcharging 1,000x
[…]
It’s apple’s fault, but they are technically within the (bad) rules.
In an ironic twist Android is not walked yet the Play Store allows you to report apps and Google actively takes action against offending apps. It even has bug bounties to find misbehaving apps do they can be dealt with.
Previously:
Sad news: for those of you who might know him, former ADN user @ClarkGoble has died of a stroke.
Clark left behind a wife and five children. There’s a GoFundMe to assist them.
His obituary is here. I knew just a small slice of him through his tech blog, comments here, and posts on Twitter and the defunct App.net.
Clark Goble may have been the single best human I ever interacted with on the internet. Patient, kind, always engaging in good faith. I admired him tremendously.
Apple today announced that Apple Arcade will be available on the App Store on Thursday, September 19 with iOS 13, offering an all-new way to enjoy games without limits. With a subscription to Apple Arcade for $4.99 per month, users get unlimited access to the entire catalog of over 100 new, exclusive games, all playable across iPhone, iPad, iPod touch, Mac and Apple TV. Apple Arcade is launching with a one-month free trial, and users will not find the games on any other mobile platform or subscription service. Apple Arcade games can all be played offline, and a single subscription includes access for up to six family members with Family Sharing.
The question is where this leaves pretty much all other gaming on Apple platforms – particularly iOS. At launch, Apple Arcade will have dozens of titles, and over 100 will arrive within “the coming weeks”; Apple is planning to add more titles every month. So for the price of a single premium iOS game each month, you’ll get access to hundreds. Quite how premium games are going to compete – even in the short term – I’ve no idea.
[…]
It’s an interesting time for Apple and games, then, and one that is filled with much promise. But it does feel ironic that the one time Apple finally gets interested in games, it may make the rest of the iOS gaming ecosystem even less viable.
Update (2019-09-13): John Gruber:
Apple should have played this video in Tuesday’s event instead of wasting so much time on a handful of live game demos. This video conveys excitement, and makes it feel like there are going to be a lot of games with a lot of variety.
Tuesday, September 10, 2019 [Tweets] [Favorites]
By naming this event “By innovation only,” Apple is really raising expectations for Tuesday, an event thus far expected to focus on iterative iPhone and Apple Watch updates. Internally, I’m told, attention has turned to more groundbreaking 2020 devices. Let’s see.
That seems to have been accurate.
Apple (MacRumors, Hacker News):
iPhone 11 Pro introduces a transformative triple-camera system with all-new Ultra Wide, Wide and Telephoto cameras, deeply integrated into iOS to create a pro-level camera experience designed for everyone.
[…]
A redesigned camera interface provides a more immersive experience that works together with the triple-camera system and all-screen display to let users see and capture the area outside of the frame. For the first time, users can easily record video without switching out of Photo mode with QuickTake by simply holding the shutter button to start recording.
What if you want to take burst photos? Hopefully, there’s a preference.
Apple’s new Night Mode (not to be confused with the new Dark Mode interface option in iOS 13) is Apple’s rejoinder to Google’s Night Sight, and from the little we’ve seen so far, the results do look at least on par with the Pixel.
When using the camera app on any of Apple’s 2019 iPhones, the new Night Mode feature comes on automatically when an indoor or outdoor scene is dark enough to warrant brightening, resulting in natural colors and reduced noise.
In short, new iPhone users should see an immediate improvement when shooting in low light environments, without having to adjust any exposure settings.
However, despite Apple’s boast that the year-old iPhone XR remains faster than the competition, Night Mode seems to be exclusive to iPhone 11, whereas Night Sight works on the Pixel 2 from 2017.
The new backs on iPhone 11/pro are actually more tacky and less slippery than XS. Quite nice feel in hand IMO.
Previously:
Update (2019-09-11): Ben Thompson:
Gurman isn’t necessarily wrong about the highly iterative nature of the hardware announcements (although I think that an always-on Apple Watch is a big deal), but that doesn’t necessarily mean he is right about the innovation question.
[…]
In the second chart you can see how Apple in 2017 not only raised prices dramatically on its flagship models, but also on the mid-tier model relative to previous flagships. This was important because it was these mid-tier models that replaced previous flagships in Apple’s usual “sell the old flagship for a $100 less per year” approach. That meant that 2017’s price hike filtered through to 2018’s 1-year old model, which increased from $549 to $599.
That means that this year actually saw three price cuts[…]
Nothing shown today really qualifies as meeting high “innovation only” expectations: Apple delivered the smallest Watch update ever, an iPad with a slightly bigger screen and nothing more, and iPhones with cameras equal to or less than many other devices. Apple needs a big 2020.
The new iPhone 11 Pros have gained a bit of weight.
• Two iPhone SEs equal one 11 Pro Max.
• The iPhone 11 Pro weighs 16g more than the 6 Plus!
• Speaking of, that iPhone 6 was damn light for its size
• Heck, you could carry NINE Watch Sports (series 0) for one 11 Pro Max
Update (2019-09-13): John Gruber:
Google beat Apple to the “night mode” game last year, but Apple’s implementation seems more natural to use. It just comes on automatically, when needed. (There is a way to turn it off, very much like turning off the camera flash.) On a Pixel, Night Sight is an entirely different mode, which I find a little weird. My guess has been that Google made Night Sight its own mode because Night Sight images, though often amazing, are also often quite unnatural. It’s so effective that it often makes nighttime scenes look like they were shot in daylight — like an old Hitchcock movie where they shot day-for-night. I hope Apple’s implementation results in more natural images — the goal should be to make it appear that the camera can see in dim lighting, not to make dark scenes look brightly lit.
[…]
Some folks will look at that list and say the iPhones 11 Pro aren’t really “pro”. I look at that list and say the regular iPhone 11 is almost just as “pro” at significantly lower prices. This is a very different dynamic between pro and non-pro models compared to MacBooks, Mac desktops, and iPads, where the pro models have very obvious performance differences.
[…]
In person, the most impressive thing about the new iPhones, to me, is the way that the entire back is made from a single piece of glass. The square section around the camera systems is milled from the same piece of glass as the rest of the back.
As happens, I got curious and went too far… may I present to you: the complete history of iPhone’s camera bump.
Below you’ll find tech specs for iPhone 11 and iPhone 11 Pro, with each difference bolded.
See also: iPhone 11 vs. iPhone XR.
iPhone 11
+25% RAM, 3 → 4GB
+6% battery, 2942 → 3110 mAhiPhone 11 Pro
+50% RAM, 4 → 6GB
+20% battery, 2658 → 3190 mAhiPhone 11 Pro Max
+50% RAM, 4 → 6GB
+10% battery, 3174 → 3500 mAh
Apple (MacRumors, Hacker News):
Apple Watch Series 5 features an innovative new display that allows the time and important information to remain visible at all times. Each watch face has been carefully optimized for the new display and to preserve battery life, the screen intelligently dims when a user’s wrist is down and returns to full brightness with a raise or a tap. Several advanced technologies work together to deliver this new feature, including the industry’s only low-temperature polysilicone and oxide display (LTPO), ultra-low power display driver, efficient power management integrated circuit and new ambient light sensor. This combination of hardware innovation and incredible software design allows Apple Watch Series 5 to offer all-day 18-hour battery life.
Didn’t see that one that coming. I still can’t see anything Apple Watch does that’s worth $400 to me, but it will be more interesting when this eventually makes it into the base model.
5 years later, Apple launches the TOTALLY FRIGGIN OBVIOUS way to sell Watches.
Update (2019-09-13): Michael Kummer:
In this article, I’ll look at what Series 5 has to offer and how it compares to Apple’s previous wearable, the Series 4. Hopefully, the information I provide here will help you decide if you should upgrade to the new model or stick with the one you have.
Josh Centers (MacRumors, Hacker News):
Apple has quietly launched the beta of a Web app for Apple Music, allowing Apple Music subscribers to access all their Apple Music content using a modern Web browser. Just about every feature you’d expect is there, except for the capability to upload music, smart playlists, some music videos, recently played custom radio stations, and curiously, Beats One radio.
MacRumors story about Apple Music web beta doesn’t seem to explicitly mention that it provides access to your personal library, not just Apple Music’s.
Apple Music now has a better iPad layout as a beta web app than a native iPad app 😬
Previously:
And to top this all off — truly, this is genuinely hard to believe — these ⌘R and ⌘L shortcuts not only break 27-year-old Finder shortcuts, but they aren’t even consistent with Photos, which uses ⌘R for “Rotate Counterclockwise” and ⌥⌘R for “Rotate Clockwise”. So in Photos the R maps to Rotate not Right, and the direction for an image rotated using ⌘R is left/counterclockwise.
[…]
There is some consistency to using ⌘L and ⌘R as shortcuts for “Rotate Left” and “Rotate Right” — those are the same command names and shortcuts that Preview uses. But there’s no reason Preview doesn’t use the same command names and shortcuts as Photos, and Photos’s use of “Clockwise” and “Counterclockwise” is, in my opinion, more clear than “Right” and “Left”.
Oh shit! So THAT’s why I occasionally find rotated photos on my machine! I’ve been wondering why that happens. And guess what I do constantly every day: Build and run in Xcode (Cmd+R) ..accidentally have a Finder window/desktop with an image file in focus? Boom.
The biggest problem with the change is not that command-R no longer reveals but that it rotates photos without any real feedback. I’ve got a ton of rotated photos now. Fuck whoever made this change, and especially didn’t put it in the menu bar so it could be disabled.
You can’t disable it, but you can use System Preferences to assign the keyboard shortcuts to other commands, i.e. back to “Make Alias” and “Show Original”. Then you run into this bug.
in 2019 ⌘R should be either “Refresh” or no-op. Browser muscle memory overrides everything else for those big shortcuts like ⌘R, ⌘T, ⌘W.
The
spctlbinary that is part of macOS’s command line interface, and has been for a very long time, are responsible for controlling what Gatekeeper looks at. These both write to asqlite3database stored at/var/db/SystemPolicy, and think of it a lot like a database of ID cards that the security guard at the desk will review. If your card is recognized, you pass through security without more than a passing hello at the barrier. If you card is not recognized, your ID is checked, your destination cleared, your name jotted down, and you’re granted a card if you belong.[…]
This system can be directly manipulated via configuration profile, and those configuration profiles can be delivered by a capable MDM. Moreover, this has been the case since macOS 10.12. Hidden away in Apple’s documentation is the SystemPolicyRule payload type, which can allow you to embed whitelisted objects in an MDM Profile.
[…]
While all of the above is intended for the
operation:installkey,operation: executewould allow you to run non-notarized Applications without Gatekeeper dialogs for those applications that are downloaded in their entirety without an installer package. You will need a separate profile if you want to whitelist both an installer and an application.
Previously:
Monday, September 9, 2019 [Tweets] [Favorites]
A shape that’s more comfortable to hold. I don’t care whether it’s rounded like the original iPhone/3G/3GS or more square like the iPhone 4/5/5s/SE. But the iPhone 6 and later just don’t feel good in hand without a case.
A more grippy texture. Again, I want to go back to not needing a case.
An antenna that’s better at picking up weak signals.
iPhone 8 size or smaller, at least as an option, without compromising the core specs.
LCD screen, unless they can fix the weird scrolling glitches with OLED ones.
Touch ID alongside Face ID.
Optical zoom for the rear camera.
A better front-facing camera.
Battery life at least as good as the iPhone XR’s.
USB-C—I think. If they’re going to switch, do it now, and update the AirPods, too.
Update (2019-09-10): See also: Michael Rockwell and Fred Wilson (Hacker News).
Apple recently adjusted its App Store search algorithm so that fewer of its own apps appear at the top of search results, senior executives Phil Schiller and Eddy Cue confirmed in an interview with The New York Times.
[…]
Mr. Schiller and Mr. Cue said the algorithm had been working properly. They simply decided to handicap themselves to help other developers.
“We make mistakes all the time,” Mr. Cue said.
“We’re happy to admit when we do,” Mr. Schiller said. “This wasn’t a mistake.”
[…]
Even after the change, analytics firm Sensor Tower found Apple apps ranked first in the App Store for over 700 search terms, even when the Apple apps were less relevant and less popular than ones from its competitors.
Jack Nicas and Keith Collins (Hacker News, AppleInsider):
Before Apple Music arrived in the App Store, Spotify was for years the first result in searches for “music.” Shortly after Apple Music was added to the store in June 2016, it took the top spot. By then, Spotify had fallen to fourth place. In Feb. 2018, Apple apps suddenly appeared in the top six results for “music”. By the end of 2018, there were eight, some of which were unrelated to music. At this point, Spotify was the 23rd result.
[…]
When multiple Apple apps packed the search results, such as in searches for “music,” the Apple executives attributed the results to a feature of the App Store search engine that sometimes grouped apps by maker. They tweaked that feature in July so Apple apps would no longer look as if they were receiving special treatment. Many Apple apps dropped as a result.
[…]
An Apple spokeswoman said the company could not verify the data because it did not keep a record of historical search results.
[…]
“I find it hard to believe that organically there are certain Apple apps that rank better than higher-reviewed, more downloaded competitors,” said Todd Dunham, chief executive of the ASO Project, which consults app makers on how to rank higher in the results.
[…]
The search algorithm in the App Store was built by a small team of engineers in Cupertino, Calif., some of whom said in a separate interview arranged by Apple that they hadn’t noticed for months that Apple was dominating search results for music and other categories.
Search is one of the biggest problems with the App Store. Why does it have such a small team? How can they improve it without keeping historical results or having automated checking for things like this?
See also: David Heinemeier Hansson.
Previously:
Update (2019-09-10): David Barnard:
Given how crude the search algorithm is, I don’t think @pschiller and @cue are lying about Apple’s apps making it to the top organically.
[…]
And this chart makes a ton of sense when you realize that iOS 10 is when Apple started allowing system apps to be deleted. From that point on Apple released more and more of their system apps on the App Store which created a feedback loop of momentum.
[…]
Here’s an example of just how bad search has been on the App Store and how blatantly developers have been manipulating with complete impunity[…]
[…]
Apple might not be lying about manipulating search themselves, but it’s 100X more embarrassing that they have allowed one of the most important experiences on their $50B/yr platform to be so broken and easy to manipulate for more than a decade.
See also: Jason Fried and Hacker News.
Update (2019-09-13): John Gruber:
Barnard’s whole thread is worth reading, and I found myself nodding along in agreement. Basically, The Times’s results are much better explained by the theory that App Store search sucks than the theory that Apple has been gaming results to harm competitors.
[…]
The fact that Apple made both Schiller and Cue available to The Times shows how seriously they take accusations of anti-competitive behavior. Let’s hope they start taking accusations of incompetent stewardship of App Store search just as seriously.
Detailed in an application for a court order filed on Thursday, the DOJ seeks names, phone numbers, IP addresses and other personal data of iOS and Android users who downloaded the Obsidian 4 app, reports Forbes.
The app, developed by American Technologies Network Corp, enables owners to connect to and control rifle scopes manufactured by the same company, specifically models in the ATN X-Sight 4K and ThOR 4 product lines. With Obsidian 4, users can connect to a compatible scope via Wi-Fi and stream live video, review images and movies stored on the scope’s microSD card and adjust hardware settings.
[…]
The DOJ is issuing the order to assist in an Immigration and Customs Enforcement investigation of illegal exports of ATN scopes.
It will be interesting to see how Apple responds, because this is not a case where it can say that it’s being asked to hack its own devices. The requested data is likely already easily accessible on its servers. And it’s not from a particular known suspect like Syed Farook; rather, this is a fishing expedition. It could also set a precedent for other types of apps that other governments want information about.
Previously:
Twitter isn’t just launching a deluge of tests -- it just announced that a few sought-after features in the pipeline. Most notably, it’s developing a long-overdue search for direct messages. Although there aren’t many specifics at this point, it’s reasonable to say this will spare you from digging through a conversation to find a crucial message from days ago. The social network added that it’s “re-energizing” its work on DMs, so this is really just the highlight of a larger strategy.
Via John Gruber:
The lack of any search at all for Twitter DMs makes iMessage search seem useful.
At least you can somewhat search DMs from the Web interface or from a mail client, if you have notifications enabled. And you can search iMessage archives using EagleFiler. But, yeah, both of these new types of messaging have, for many years, had a worse search experience than e-mail and the forms of chat that preceded them.
Friday, September 6, 2019 [Tweets] [Favorites]
Apple (Hacker News):
Last week, Google published a blog about vulnerabilities that Apple fixed for iOS users in February.
“A blog,” rather than “a blog post”? I love how Apple is subtly trying to discredit Project Zero by implying that it’s a mere blog. And let’s be sure everyone knows it’s affiliated with Google, the privacy bad guys, even though it’s a responsible, technically focused group. Of course, the quote you’re reading is not from a blog by Apple PR. It’s an “Apple Statement.” From the Newsroom. Which has an RSS feed, like blogs do. (Though the feed isn’t discoverable from the statement page.)
First, the sophisticated attack was narrowly focused, not a broad-based exploit of iPhones “en masse” as described.
Project Zero literally referred to “a small collection of hacked websites” that received “receive thousands of visitors per week.” And it does seem like a particular subpopulation was targeted “en masse.” The sites in question were on the public Internet; it wasn’t links being sent to target particular individuals. Apple is blaming the messenger for things it didn’t even say.
The attack affected fewer than a dozen websites that focus on content related to the Uighur community.
Oh, I get it. Most people would consider “fewer than a dozen” to be “a small collection.” But in Apple-speak, there were “a small number” of corrupt App Store binaries causing crashes, and “a small number” of MacBook Pro users experiencing butterfly keyboard problems, not to be confused with the “very small number” of iPhones that unexpectedly shut down. So, yeah, I can see why Apple wants people to know that this “small collection” doesn’t mean “millions.” Although there are apparently 10 million Uigurs in China…
Google’s post, issued six months after iOS patches were released[…]
It’s great that Project Zero reported this in a responsible way, because now we can downplay it as old news.
Second, all evidence indicates that these website attacks were only operational for a brief period, roughly two months, not “two years” as Google implies.
I’m not sure how they know that there weren’t other sites than the ones they considered. Why would someone go to the trouble of targeting iOS 10.0.1 separately from iOS 10.3—or even target iOS 10 at all—if the attack was only for two months in 2018 (after iOS 12 was out)?
We fixed the vulnerabilities in question in February — working extremely quickly to resolve the issue just 10 days after we learned about it. When Google approached us, we were already in the process of fixing the exploited bugs.
Apparently, this is because they were tipped off by the FBI first, but mentioning that would make this seems more serious than Apple wants. This way they get to pretend that they’re smarter than Google.
Overall, an odd response from Apple. Maybe this is really smart PR before the big event next week. But, from my perspective, it is not a good look.
Lorenzo Franceschi-Bicchierai:
I’ve never seen a more smug statement after a breach. Let’s remember that this affects a minority that is actively being suppressed and effectively annihilated by the Chinese government. Perhaps dismissing the gravity of the hacks is not the best approach.
This is trash. The us vs them is just gross and disingenuous. Project Zero is doing all of us a service, and Apple PR should be embarrassed for having written this.
In a blog post, the iPhone-maker took issue with some of the findings released by Google researchers[…]
“A blog post”!
In a response Friday, a Google spokesperson said the company stood by its research, “which was written to focus on the technical aspects of these vulnerabilities.”
Reading between the lines here, what Apple is pushing back on is the fact that Google’s report on this attack against the Uyghur community only mentioned iOS. […] Conspicuously unmentioned in Apple’s response: “China”.
Of course, Project Zero does also publish blogs about Android exploits. And nothing is stopping Apple’s security team from publishing a blog about Android.
One of the sources told TechCrunch that the websites also infected non-Uygurs who inadvertently accessed these domains because they were indexed in Google search, prompting the FBI to alert Google to ask for the site to be removed from its index to prevent infections.
This upends pretty much everything we know about iPhone hacking. We believed that it was hard. We believed that effective zero-day exploits cost $2M or $3M, and were used sparingly by governments only against high-value targets. We believed that if an exploit was used too frequently, it would be quickly discovered and patched.
None of that is true here. This operation used fourteen zero-days exploits. It used them indiscriminately. And it remained undetected for two years.
Previously:
Update (2019-09-06): I’m still fascinated by the “fewer than a dozen” phrasing. Surely, Apple would want us to know if it were fewer than ten, i.e. single digits. So the number is likely ten or eleven, yet they didn’t want to say the exact number. And I don’t think the number of sites is actually that important. A single popular site would be worse than many small ones. The number that matters is how many people were affected, and it’s likely not small. Yet this is the lead “fact” that Apple wanted to communicate.
It’s also worth noting that this response dropped on a Friday, and that it doesn’t include a link to the post it’s critiquing, or mention its title or author. So if you don’t actually read it for yourself, you’re left with the implication that it was some sort of dishonest corporate smear campaign.
See also: MacRumors, The Verge, Zeynep Tufekci.
Lorenzo Franceschi-Bicchierai:
A former Apple security employee criticized the company’s reaction and its statement, saying it was misleading. For example, the former employee said, the fact that the the attack was narrowly focused “doesn’t say anything about the security of iOS, merely about the restraint of Chinese attackers.”
“There was nothing keeping the Chinese from putting their exploit(s) in an advertising iframe and paying Huffington Post to serve it. They could easily have compromised tens of millions of iPhones, but chose not to. As a result, we didn’t find out about these attackers for years,” the employee, who spoke on condition of anonymity, said.
I don’t care a whit for the drama at play here. Bottom line: iOS isn’t nearly as secure as Apple led us to believe.
Here’s the thing: Apple took away a lot of freedoms in exchange for two promises:
- No junk apps.
- No major security isssues.
Apple is not upholding their end of the bargain.
Update (2019-09-07): Nick Heer:
So why did Apple respond to that Project Zero disclosure anyway? The researchers stated that the exploits had been patched months ago. Apple offered no new information in their statement. What was the point?
I think it’s because some of the reporting sensationalized Project Zero’s work and didn’t make it clear that the patches were already in place. Apple chose to attack Google, rather than the media responsible for that coverage.
That might also have been avoided if Apple had kept its own customers informed about its products, instead of leaving its competitor to disclose the biggest security incident in iOS history. Now, every time Apple touts how secure its stuff is, you have to wonder whether there are more incidents like this that they are hiding from you, which is a shame because I think they’re doing a pretty good job with the actual security work.
Apple’s response to the worst known iOS attack in history should be graded somewhere between “disappointing” and “disgusting”.
First off, disputing Google’s correct use of “indiscriminate” when describing a watering hole attack smacks of “it’s ok, it didn’t hit white people.”
[…]
Even if we accept Apple’s framing that exploiting Uyghurs isn’t as big a deal as Google makes it out to be, they have no idea whether these exploits were used by the PRC in more targeted situations. Dismissing such a possibility out of hand is extremely risky.
[…]
Third, the pivot to Apple’s arrogant marketing is not only tone-deaf but really rings hollow to the security community when Google did all the heavy lifting here.
[…]
Apple does some incredible security work, but this kind of legal/comms driven response can undermine that work.
Update (2019-09-09): James O’Leary:
mind-boggling own goal to bring this up, unprompted, days later, much less pick a fight with project zero, that never ends well
Something seems up with Cook the last year or so, this + the Spotify response were obfuscatory, unnecessary, and reeked of defensiveness
I read Apple’s response, which was clearly very defensive. While I dismissed Google’s efforts as a chance to puncture Apple’s privacy blimp (Google is really good at shifting attention away from its own dirty privacy tricks), but Apple’s statement is what has raised some red flags for me. What are they not telling us? And why are they telling us now, so long after the fact? Why not come clean earlier?
The series of exploit chains Google wrote about are entirely different. They’re comprehensive — they span multiple major and minor versions of iOS. They’re targeted to surveil an entire persecuted group of people, which makes them far more exposed than specific user applications but not as indiscriminate as a computer virus. Make no mistake: this was an exploitation deployed “en masse”, exactly as Google says.
Apple’s acknowledgement that users would be exposed only if they visited one of “fewer than a dozen websites” is a little misleading as well.
[…]
Neither company has disclosed which websites were spreading these exploit chains, however, so it’s impossible to say whether your iPhone is likely to be affected. Apple’s disputes seem to be about little more than language choices.
[…]
Their statement says nothing, but it does remind people of a reputational failure. […] If Apple did not want to engage with the troubling abuse of their platform to help surveil Uyghurs — and I think they should have, for what it’s worth, but I understand the economic risks of speaking up against the Chinese government — why not issue a succinct release solely about security?
Aside from everything else, using PR to minimize the significance of discovered vulnerabilities is number one on my list of things that make me trust a vendor’s products less. The response to a flaw tells us far more about the security of a product than the flaw itself.
The time-to-patch tells you something about the security and engineering teams. The PR response teaches you about the exec suite.
This is also a classic case of Apple taking the wrong token. They went with “it’s no big deal” when they should have gone with “it’s the end of the world”. They could have asked @gassee, who used to run Apple France, for a primer on this concept.
Update (2019-09-10): See also: Slashdot.
Annie Lowrey (via Hacker News):
If you take a vehicle loaned out by Zipcar—a rental service where drivers use RFID cards or a mobile app to open up the car—to an area without cell reception, there’s a chance the car will not work. The doors won’t open, and even if they do, the engine will not start. And because you will be in an area with no cell reception, it might be impossible for you to call for help.
[…]
Zipcars in general work just fine when they do not have cell service, he said, as they have some internal memory that lets them function even when out of touch with the company servers. Indeed, making sure that the cars work when out of reception is a “mission-critical success factor” for the company, he said. Still, cars without reception become vulnerable in a few scenarios: when members lose or do not have their physical Zipcard with them, when they exceed their reservation time or want to extend their Zipcar reservation, or when the vehicle battery dies. That last scenario was the one my family and I found ourselves in, though we did not know it at the time.
[…]
He was amazed—and I was amazed—in part because Zipcar does not warn users that they need to take extra precautions in areas without reception, whether the bowels of parking garages or overlook points on mountainous roads.
I wonder if the car battery died because it was continually searching for a faint cell signal.
Thursday, September 5, 2019 [Tweets] [Favorites]
The upcoming fingerprint reader would be embedded in the screen, letting a user scan their fingerprint on a large portion of the display, and it would work in tandem with the existing Face ID system, the people familiar with Apple’s plans said.
[…]
Apple is considering including this in-screen touch sensor in the 2020 iPhone model if testing is successful, the people said. Suppliers have proven their ability to integrate the technology into iPhones, but the company has not managed to mass-produce it yet, one person familiar with the development work said.
Having redundant sensors sounds wasteful, but I’m looking forward to this. The longer I use Face ID, the more I’m annoyed at how much slower it makes the common case of unlocking my phone as I pull it out of my pocket. Yet I don’t want to switch back to only Touch ID because there are cases where it doesn’t work at all.
Previously:
Update (2019-09-06): John Gruber:
If true, I would guess this would be an optional way to increase security by requiring both Face ID and Touch ID authentication.
Update (2019-09-09): Joe Rossignol:
“Certainly, we’ll continue to put [Face ID] on more devices but also Touch ID will continue to have a role - it’s a great technology on our iPad lineup and we don’t see it going away anytime soon,” said Joswiak.
When Google puts 4 paid ads ahead of the first organic result for your own brand name, you’re forced to pay up if you want to be found. It’s a shakedown. It’s ransom.
It’s totally crazy for google to get away with charging what’s basically protection money on your own brand name. “Nice high intend traffic you got there, would be a shame if something were to happen to it”
And of course, Google doesn’t let you target any of their own trademarks this way, and won’t even let you mention “Google” in your ad text. And Google no longer visually styles paid results distinctively from actual search results — just the little “Ad” icon before the result URL.
I think it’s useful to be able to find out about related products through ads. What feels wrong is that the ads don’t really look like ads. It looks like a list of results where the organic one, which is almost certainly what the person wants, is never at the top. So, (a) you have to pay to be where you should have been anyway, and (b) some customers will click the first result and end up somewhere unexpected.
Lots of misleading ads also...
See also App Store ads
E.g. search for Things, then the first and full scale entry is a competitor that paid.
Apple sure is better than Google.
At least Apple uses a different color for the ad.
We even got a call from an Apple sales rep who made clear that we need to bid on our own keywords/brand name to make sure that we are at first place and not one of our competitors…
For once, maybe it’s good that the Mac App Store doesn’t have feature parity.
Data from Jumpshot says that more than 50% of Google searches in June didn’t result in a click. The results show that organic search clicks are going down even as paid Google search clicks are going up, as are searches to result in no clicks whatsoever. For brands, businesses and marketers who rely on organic Google search results to drive commerce, this means recalibrating how they think of Google in their plans.
Google is slowly but surely choking the web. This is what monopoly power inevitably leads to. The noblest of founding intentions is no match for the imperative.
For basic searches like “maps,” Apple’s apps ranked first more than 60 percent of the time in the WSJ’s testing. Apps that generate revenue like Music or Books showed up first in 95 percent of related searches.
[…]
Apple says that it uses an algorithm that uses machine learning and past consumer preferences, leading to app rankings that often fluctuate. Apple suggested that its apps ranked first in the WSJ’s testing because those apps are popular with consumers. Apple says that all apps are subjected to the same search algorithm, including its own.
Previously:
Update (2019-09-06): Kyle Howells:
It’s shameful how Google has regressed from clearly showing ads, to gradually trying to hide them and trick people into thinking they are the search results.
On 29 August 2019, Google’s Project Zero security research team released the details of a major series of attacks against iOS using sophisticated, zero-day exploits on a scale unprecedented in the iOS world. (Wired has a less technical summary of the Project Zero report, which is aimed at security professionals.) This is the most significant iOS security incident we are aware of since the launch of the iPhone. And while it’s extremely unlikely that any TidBITS readers had their devices compromised, the news remains a concerning development.
[…]
Infection was easy: if a user visited one of the hacked Web sites using an iOS device, that device would be infected with implanted malware without having to interact with the user in any way. That malware could monitor the infected device’s GPS location data in real time, up to once per minute. It could also steal files on the device[…]
[…]
First off, because Google reported all the exploits to Apple quickly, and Apple responded by patching them all in iOS within days, you’re protected from these particular attacks as long as you’re running an updated version of iOS. The implant malware could also be removed merely by restarting the iPhone.
The Zerodium CEO said “the zero-day market is so flooded by iOS exploits” that they are now refusing them
Also, check out this statement regarding iOS security.
Chance Miller (via Yan Zhu):
Google today has rolled out an update to the Gmail app for iOS that gives users the ability to further curtail email tracking. The latest update adds a new setting that allows users to block external images in emails from being displayed automatically.
With today’s update, users can choose to be asked each time whether or not to display external images in an email. This includes email trackers that can be hidden in the body of emails.
Every e-mail client should offer this.
Previously:
Wednesday, September 4, 2019 [Tweets] [Favorites]
As a reminder, Mac software distributed outside the Mac App Store must be notarized by Apple in order to run on macOS Catalina. To make this transition easier and to protect users on macOS Catalina who continue to use older versions of software, we’ve adjusted the notarization prerequisites until January 2020.
You can now notarize Mac software that:
- Doesn’t have the Hardened Runtime capability enabled.
- Has components not signed with your Developer ID.
- Doesn’t include a secure timestamp with your code-signing signature.
- Was built with an older SDK.
- Includes the com.apple.security.get-task-allow entitlement with the value set to any variation of true.
This makes a lot of sense because the main benefit of notarization is the malware scan. It was never necessary to bundle that with all the other requirements.
It’s super important to check the logs because the warnings will become fatal errors again come January, 2020!
IMO, they have failed at both the end-user level and the developer level. This delay, while helpful, doesn’t address the core issues.
There is no easy way to tell if an app is notarized. End-users can’t tell which apps are or are not notarized.
I agree that there remain problems, but I don’t think this is something that end users need to be concerned with checking. Except for unusual ways of getting an app onto a Mac, and manually bypassing the launch check, the system is going to enforce that everything is notarized.
This does still mean you need to get notarized packages, zips and disk images for your environment if you intend to have 3rd party non-AppStorer software installed directly by end users. If you are installing tools via Munki’s LaunchDaemons or Jamf’s framework, this doesn’t apply yet.
Previously:
Update (2019-09-06): Howard Oakley:
It’s also worth noting that some developers have reported that apps which have been successfully notarized don’t always complete Catalina’s first run Gatekeeper checks successfully, and as a result Catalina may refuse to open them.
Update (2019-09-09): Isaiah Carew:
relaxing the deadlines does not solve the terrible user experience issues.
nor the issue that you can’t staple a notarization receipt to a zip file.
even just in the public beta, the problems are already so numerous that i have a one-button form response to the issue.
As a user though I’m now left in doubt. Was all this performance with notarization and claims of its security benefits actually genuine? If so, why is this being postponed further, giving another three or more months of exploits? Or maybe Apple had overstated its benefits, in which case how is Catalina going to improve security, other than with its read-only system volume? If hardening and strict notarization do bring significant security benefits, why doesn’t macOS let me know which apps are well-prepared, and which are not?
Update (2019-09-10): Rosyna Keller:
Plugins are able to be stapled since Xcode 10.2.
See also: Howard Oakley.
Here are my definitions:
development (d): everything is in progress and the app might be completely unusable.
alpha (a): the app is feature-complete and has no known bugs — but, importantly, it’s had very little testing.
beta (b): the app is feature-complete, has no known bugs, and has been tested — but further testing is still warranted. Every beta is a release candidate.
The definitions I like to use, which I think originally came from Apple’s guidelines, are the same except that known bugs are allowed in the alpha stage. In any case, Apple and most of the rest of the world have moved on to other definitions. All of Apple’s betas these days have known bugs, and they’re usually not feature complete.
Wikipedia (via Hacker News):
Tom Van Vleck, a Multics engineer, has also reminisced about the extension rc: “The idea of having the command processing shell be an ordinary slave program came from the Multics design, and a predecessor program on CTSS by Louis Pouzin called RUNCOM, the source of the ‘.rc’ suffix on some Unix configuration files.”
Previously:
You can move your audiobooks to the Books app, which offers a number of features for playback that are more appropriate for listening to spoken word. For example, you click buttons to skip ahead or back by 15 seconds, set a sleep timer, and more. However, these files are stored on your startup disk, and you may simply not have enough space on this disk[…]
[…]
Or you can keep your audiobooks in your Music library. If you rip audiobook CDs, their files can stay in your Music library, and you can listen to them in the Music app, sync them to an iOS device, and even put them in your iCloud Music Library, if the bit rate is 96 kbps or above.
Previously:
Tuesday, September 3, 2019 [Tweets] [Favorites]
PSA: Even iOS 13.1 beta did not bring back iCloud folder sharing. (Dropped in 13.0 beta 4 or 5?)
Catalina beta 7 still seems to be lacking major iCloud prime-time stability.
It seems that Apple has done a full rollback of basically all iCloud changes from Catalina / iOS 13.
The sync agent “bird” is back, as is “brctl”. Gone is the new “iCloudDrive” agent. No folder sharing until at least iOS 13.2, it seems. Maybe even iOS 14?
Better for us that this time, the rollback came during beta. I applaud that they rather don’t ship features then ship them in a broken state.
Interesting but unsurprising news: it appears most/all of the iCloud Drive improvements announced at WWDC (pinned files that remain downloaded locally, shared folders) will have to wait until iOS 13.2 at the earliest.
iCloud Drive is simply far too important for it to be buggy.
My iCloud drive is littered with duplicate folders. I’m not sure when in the beta cycle this happened but it’s a mess.
If app folders are missing from iCloud Drive on macOS Catalina beta 7:
- 1. Disable iCloud Drive in System Preferences → Apple ID
- 2. Run this command in Terminal:
find ~/Library/Mobile\ Documents/*/Documents -type l -maxdepth 0 -exec rm '{}' ';'- 3. Enable iCloud Drive.
Previously:
Update (2019-09-05): Craig Hockenberry:
And when I say lost, I mean really lost. Entire folders were either gone or corrupted. Apple’s mechanism to recover deleted files was of no help. The customers with weird folder duplicates were the “lucky” ones.
[…]
A few weeks later, Apple finally indicated that there were some issues with iCloud and the beta release. In the same week, they released a public beta and sent out an email to customers encouraging them to try out iOS 13.
We did our best to understand the situation and provide information to Apple, but it felt like we were tossing bug reports into a black hole. The most discouraging part was when we tried to open an incident with Apple Developer Technical Support (DTS). After writing up a detailed report, we were informed that they don’t support beta releases!
[…]
If a device is using an Apple ID that’s also being used on a non-beta device, then iCloud shouldn’t be allowed. If you install an iOS beta on your iPad, it doesn’t get to use any cloud services because it puts the data on your iPhone or Mac at risk.
[…]
As it is now, Apple is effectively telling you that your storage device will be unreliable for a few months. It’s like having a hard drive where the manufacturer tells you it won’t work well for ¼ of the year. Would you purchase storage with a caveat that “the drive mechanism may not work properly during the hot summer months”?
Previously:
I’ve been doing this long enough to remember when the .Mac APIs were built against an SDK. I understand why Apple ties iCloud API updates to OS releases, but I really wish they wouldn’t. Apple’s coders are smart enough to make things backwards compatible, and being able to deploy new iCloud APIs to last year’s OS release would be a nice win for everyone.
[…]
I’ve barely tested it this year, precisely because of the iCloud issues people were encountering.
I think it is fair to say that Apple have always struggled with iCloud Drive, as this post from 2015 shows.
This years iOS/iPadOS release cycle was a mess. The first public beta was surprisingly early considering how broken the first beta seeds were. Even in the current beta many things are still too buggy. I’ll recommend everyone who asks me to wait for 13.1!
But I actually think having the ability to backup and restore all of your iCloud data is a more attainable first step that would mitigate a lot of fear from situations like this in the future. Essentially, Apple could prevent beta releases of iOS from touching iCloud data unless the service first confirms that the user has completed a download of an iCloud backup file. Then, if anything goes wrong, the user can at least restore from that point.
A positive in this is that it makes it considerably easier for us to drop our long-suffering iCloud support in 4.0 and consign it to the curmudgeon-accommodating Pleco Legacy app.
I literally have a support email in my inbox right now about somebody losing their iCloud-synced flashcards due to an iOS 13 beta bug; if Apple’s willing to ship a public release with broken iCloud then it’s clear it can no longer be relied upon.
Update (2019-09-09): Jacob Pritchett:
I’m a musician, and within a couple of days of installing iOS 13 on my iPhone, my Logic Pro X projects (I store them in iCloud) were all replaced with 0 kB shells.
Even though I hadn’t installed Catalina on any of my Macs.
I’m also a digital artist, and I lost most of my art too.
The result is that I lost the better half of a decade of my music, including dozens of unreleased tracks. It was absolutely devastating.
I would never have thought that installing a beta on my iPhone (I’m an iOS app developer by trade, so I need to) could possibly cause issues on my Mac, which I specifically avoided updating to a beta because I use it for important projects.
I recently released a menu bar Mac app called Red Eye. It’s free and you can download it here. It prevents your Mac from going to sleep.
[…]
Unfortunately, Red Eye was rejected from the Mac App Store. I wanted to distribute there, as well as independently. The first reason was a Human Interface Guidelines violation, because you have to right-click Red Eye in the menu bar to open the menu to quit the app, which reviewers said is “confusing to users”. I think that’s debatable. The second reason for rejection was for “duplicate functionality that already exists in the Mac App Store”, which I think is bullshit and arbitrary. I counted three dozen Markdown editors in the Mac App Store before I got tired of scrolling through the search results. It is especially frustrating when the Mac App Store is also full of fucking scams.
