Tony Fadell:
Ironically, when we couldn’t get any more money, I got a phone call from Apple saying, “Hey, come on in. We want to talk to you.” It turned out to be, we have iTunes, we’re making mix CDs, and these MP3 players out there are really bad. We think there’s a way to make an Apple version. Come on as a consultant for eight weeks, see what you can design, and we’ll see what we like. That was it.
[…]
I’d go around to other people in the company because I needed their help. Jack Williams, the COO, he was in one of the very first meetings I was in. I didn’t know who he was. I turned to him and said, “I need you to do this.” He said, “What is this?” “I’m making this music player!” No one believed it. People did not believe it. We’re fighting for our lives here. What are we doing with this little toy? That’s what it looked like.
[…]
I turned to Steve and said, “We can build anything. Give it enough time and money. But how can you guarantee to me that you can sell and market it? Look at Sony. They own every audio category. How do we go up against that?” He said to me, “Look. You make it, and I guarantee I’ll use every marketing dollar I’ve got. I’ll starve the Mac to do it.”
[…]
There was no master plan. We were living day to day. We started with iTunes, so you can rip CDs and make mix CDs. Then people want something more than a CD, something convenient to put their music on. Then they’re ripping CDs to get their music, so there has to be a better way. That was when digital downloads and then iTunes Music Store happened.
Via Juli Clover:
After being pressured by much of the iPod team to get iTunes to the biggest market, Jobs relented, but he insisted that journalist Walt Mossberg, who wrote for The Wall Street Journal at the time, sign off on the design.
History iPod iTunes iTunes Store Mac Marketing Steve Jobs Windows
Matt Gallagher:
Instead of using log files to track asynchronous tasks, I prefer to use a structure that I call a “task journal”.
[…]
We’d have a bit more flexibility if we could use the C function backtrace but in Swift, we can’t. The backtrace function comes from the “execinfo.h” header and is implemented as part of libSystem on OS X and iOS (which all Swift programs link against) but for whatever reason, the “execinfo.h” contents are not exposed to Swift programs.
[…]
The resulting callStackReturnAddresses function is about twice as fast as NSThread.callStackReturnAddresses on the basic tests I’ve tried (roughly 2 million invocations per second per core on my Mac versus 1 million invocations per second for NSThread.callStackReturnAddresses). It’s easily fast enough to gather lots of data in Debug builds – even for fairly intensive computational paths.
Cocoa Debugging iOS Mac Open Source Programming Swift Programming Language
Károly Lőrentey (via Nick Lockwood):
The benchmark above demonstrates this really well: insertion into a sorted array is O(n^2) when there are
many items, but it is still much faster than a red-black tree with its attractive-looking O(n * log(n))
solution. At the beginning of the curve, up to about eighteen thousand items, a sorted array
implementation imported from an external module is very consistently about 6-7 faster than a red-black tree,
with a slope that is indistinguishable from O(n * log(n)). Even after it catches up to quadratic complexity,
it takes about a hundred thousand items for the sorted array to become slower than the red-black tree!
This remarkable result is due in large part to the vast number of (to a CPU, random-looking) memory references that are
needed to operate on red-black trees.
[…]
Note that the big gap between collections imported from stdlib and those imported from external modules is caused by a limitation in the current Swift compiler/ABI: when this limitation is lifted, the gap will narrow considerably, which will reduce the element count at which you’ll be able to reap the benefits of lower asymptotic complexity.
[…]
The all-or-nothing copy-on-write behavior of Array, Dictionary and Set can lead to performance problems
that are hard to detect and fix.
If the underlying storage buffer is being shared by multiple collection instances, the modification of a single element
in any of the instances requires creating a full copy of every element.
It is not at all obvious from the code when this happens, and it is even harder to reliably check for.
You can’t (easily) write unit tests to check against accidental copying of items with value semantics!
With standard collection types, you often need to think about memory management.
Algorithm CS Theory Open Source Optimization Programming Swift Programming Language
Graham Spencer:
Inconsistency from App Review was another major recurring theme in the survey responses. Numerous developers gave examples where App Review had approved an update containing new features, only to reject a subsequent update for those features which had previously been approved. The most frustrating of those examples were when the update was a bug fix – meaning the developer, trying to quickly resolve an issue for their users, would now have to take more time either modifying their app to comply or appeal the decision (which may not succeed).
One such example was when a small bug fix led to App Review rejecting an app because it required registration. But the app, which had been on the App Store for five years, had always required registration and all of their competitors did the same thing. In the end the app was approved, but it took about a month of appeals and several phone calls to Apple from the developer.
Most concerning was the idea, alluded to in a few of the responses, that some apps were being left to stagnate and die because developers felt that going through App Review again was too risky. These developers felt it was better to just let the app die slowly than risk going through what they feel is an inconsistent App Review, which might reject a long-standing feature – the removal of which would instantly kill the utility of the app.
[…]
A few developers wrote in and described how an app had been stuck in the App Review process for weeks and even months. What frustrated many of these developers was not just the excruciatingly long time in review, but the utter lack of communication from Apple as to why they were in App Review limbo. […] There is a mechanism for developers to send messages to the App Review team, but a common sentiment amongst those who commented on it was that it can often be (or at least appear to be) futile. One developer said App Review simply sends them “canned responses” and another developer even described the feeling of communicating with App Review as “like sending a message in a bottle”.
[…]
One developer had an app update held “in review” for 32 days. Whenever the developer contacted App Review during this time, they were told nothing was wrong. Eventually the developer contacted someone at Apple they knew and this resulted in a call back from someone in App Review. They asked the developer why they were using HomeKit devices that were unreleased and that the developer should not have access to. Only wrinkle was, the developer was not using any unreleased HomeKit devices.
App Review App Store Business iOS Mac Mac App Store
Dave DeLong:
This is where another calendrical technique called “intercalation” comes in. Intercalation is the process of inserting or removing a unit of time measurement (like a day) into your calendar to get it to line up with whatever natural cycle off which you’re based.
[…]
This Gregorian system of an intercalary day is well-known to us and we’re pretty used to it. But once you get out of the western mindset of “January - December” and accounting for all the other billions of people around the world who measure time differently, you realize some key things, and one of the big ones is that intercalation is not limited to days or seconds.
[…]
The Japanese calendar is a prime example of not making assumptions about dates. While the days and months are all based on the Gregorian calendar, the year is measured from the day that the current emperor ascended to the throne. And when an emperor passes on, a new year begins the very next day, even if it’s not actually the Gregorian “new year”.
Previously: Falsehoods Programmers Believe.
Programming Time
Ashley Nelson-Hornstein:
I recently shattered the screen of my iPhone 6S. Since then, every Apple fan I’ve spoken with has asked me if I have AppleCare+, and each has given me the same pitying look of sympathy when I say no. “You should really get that,” they say. Well, today I looked at the numbers and I still don’t see a point to Apple’s warranty program for iPhones.
AppleCare iPhone
