My thanks to Emerge for sponsoring the blog this week.
Emerge helps teams build better, smaller apps. It offers binary profiling to enable developers to see the full impact of their changes as they make them and actionable insights to provide suggestions on ways devs can improve their code.
Emerge integrates with your CI workflow and comments on your pull requests with granular binary size diffs and insights. Developers can dive even deeper on Emerge’s platform with interactive visualizations that enable you to explore and understand your app’s binary, track your app size over time, and even compare your app against competitors!
Our team has experience reducing the size of Airbnb’s iOS app by over 10%. Now we’re bringing our new development experience to apps everywhere.
Want to see an example of Emerge’s build analysis? 🧐 Check out an App Store build of Reddit.
🚀 Get started with Emerge right now!
Airbnb Developer Tool GitHub iOS iOS 14 Optimization Programming Reddit Sponsor
Joanna Stern:
All it takes is some bedtime reading of Epic’s 365-page findings document to see just how aggressive Apple executives have gotten in carrying out Steve Jobs’ 2010 vision to, as the finding document quotes him, “tie all our products together so we further lock customers into our ecosystem.”
[…]
Those of us living with multiple Apple gadgets know the garden is pretty darn nice. We’re suffering no more than that person seated in first class next to the lavatory. But are we missing out?
I set up camp in the increasingly harmonious Android/Windows garden, talked to experts and dug through court documents. In the end, I found three strong reasons to justify Apple’s garden—and three strong reasons we need more holes in its walls.
John Gruber:
The people who use the term “walled garden” in this context typically do so as a pejorative. But that’s not right. Literal walled gardens can be very nice — and the walls and gates can be what makes them nice.
[…]
Better than “walled garden”, I like the comparison to theme parks. People love theme parks. Not everyone, of course, but a lot of people. They’re fun, safe, and deliver a designed experience. They’re also expensive, and the food, to put it kindly, generally sucks.
Point taken, but I think this analogy breaks down because:
A walled garden is not the only way of achieving the benefits he describes. For example, Apple could have made uninstalling easy on the Mac, if it wanted to.
The promise is that iOS and the App Store offer a Disneyesque experience, but that’s far from the reality. One of my main takeways from the Epic trial is how successful the marketing as been, how many people believe Apple is protecting them in ways that it absolutely is not. Poorly built walls can actually make things worse. iOS is not Disneyland. Android, despite the FUD, is not Action Park.
And, even if they were, those shouldn’t be the only two choices. iOS is not a place where you choose to vacation now and then. It’s where you live. The world shouldn’t be limited to two theme parks that you can never leave.
Dieter Bohn:
During the Epic v. Apple trial, a new metaphor popped into my head and I can’t shake it. As I was looking at the emails that Apple executives were sending each other and reading their testimony during the trial, I kept thinking I’d seen this kind of behavior and even some of the justifications before. And so here it is:
Apple is a carrier.
I mean “carrier” as in cellular network carrier, as in Apple is Verizon or T-Mobile or (shudder) AT&T. Here’s how the metaphor works: The most important thing to any carrier is feeding the Angry God of ARPU (average revenue per user). That number must go up to please shareholders and pay executives, and the carriers have engaged in any number of shenanigans to make it happen.
[…]
Before the iPhone, carriers could (and did) point to any number of smartphones and rightfully boast about the incredible things those phones enabled. The Blackberry, the Treo, the Moto Q, and more all did things that nobody would have thought possible just a few years before. But the carriers would take credit for them while at the same time making demands that kneecapped those phones’ capabilities. They used their monopoly on wireless customers to dictate phone design, software capabilities, and business models.
Indeed.
Previously:
Update (2021-06-07): Nilay Patel:
Smartphones are not just a nice thing you can have — they are the primary (and often only) computer for vast numbers of people. They are a conduit of culture! Condemning all those people to living in a “theme park” is even worse than a “walled garden” imo
Antitrust App Store Apple Epic iOS iOS 14
Daniel Martín:
Just found that the old Apple conceptual documentation is still available for offline searches. Extract the .docset from the .dmg and load it in a tool like Dash.
There’s a lot of good stuff in here that has been removed without replacement from the current docs. Opening the package produces an error from the Installer app:
This package is incompatible with this version of macOS.
The package is trying to install content to the system volume. Contact the software manufacturer for assistance.
But you can expand it via Terminal:
pkgutil --expand-full /Volumes/ConceptualDocset/ConceptualDocset.pkg ~/Downloads/ConceptualDocset
Update (2021-06-13): Howard Oakley:
Third-party attempts to document Mac OS X have been brave, but none has stood the pace of change. Amit Singh’s Mac OS X Internals from 2006 was replaced around 2017 by Jonathan Levin’s outstanding trilogy *OS Internals, which was marred only by its lack of an index. But no sooner had Levin completed his series than he abandoned it in favour of documenting Android.
DocC looks exciting, and demonstrates that Apple recognises its problem, at least in part. But it falls into several well-known traps.
First, it concentrates on documenting calls within an API by individual function. For a developer who already understands how that sub-system in macOS works, that’s essential. But trying to grok major topics like Attributed Text simply isn’t possible by referring to individual functions within the API. You first need to get your head around how sub-systems are designed and function, the conceptual information which Apple was once so good at providing. Good conceptual documentation is structured and written quite differently from that for classes and functions with an API, as Apple well knows.
Update (2021-06-18): See also: Hacker News.
giantrobot:
From my perspective, I was in SWE at Apple for over a decade, their documentation started going downhill as iOS development ramped up. By the time they got to the yearly release cycle for macOS and iOS documentation was an afterthought. Most was generated with doxygen from inline docstrings.
The reason I think the quality and quantity dropped was the internal schedules barely (or don’t) leave enough time for the engineering work so there’s very little time available for high level documentation. Internally tons of “documentation” existed as Radar comments or exchanges on internal mailing lists. Maybe a group’s wiki had some crystallized documentation or high level architectural descriptions but good luck accessing it from outside that org. My favorite was some discussion about overall design or architecture that got the “let’s take this offline” where all the helpful details ended up shared in an in-person meeting.
The internal secrecy and rapid development pace made it really difficult to get good overviews of technologies internally.
DocC Documentation History Mac Programming
This is really cool, and I just realized that I forgot to link to it after last year’s WWDC.
Pierre Habouzit:
Faster, priority-inversion-less GC (speed)
@mikeash wrote about it a long time ago, however it turns out this was relatively slow and could also fail (if a thread was observed in the critical section).
The general idea is still the same, but instead of observing the other threads PC, we use a scheme where at startup the runtime tells the kernel where the code reading the IMP caches “unsafely” is, and gives a “recovery PC”.
Now when a GC is triggered, instead of asking for all the other threads PCs, the kernel is told to “force” the PC of threads in the critical section to the recovery path, there’s no waiting, and it can’t fail.
it’s also 10-100x as fast as before.
David Smith:
This is one of the wildest optimizations I’ve seen. How do you make a reader-writer lock with zero instructions? You uh… ask the kernel to move all the reader threads out of the critical section 😱😱😱
Just like… longjmp someone else from outside 🤯
Pierre Habouzit:
I really feel that working at
@Apple
gives one a unique convergence of “all the things” that is mostly unmatched in the rest of the industry and some of us are lucky enough to have the opportunity to take advantage of it ;)
Previously:
Concurrency Garbarge Collection iOS iOS 14 Kernel Mac macOS 11.0 Big Sur Memory Management Objective-C Runtime Optimization Programming
