Dave DeLong:
Settings in configuration files can be configured to have different values based on certain conditions (namely, the name of the SDK being used and/or the architecture being built).
This, combined with a certain build setting, gives us everything we need to have nicer conditional compilation.
[…]
Now we have something that’s much clearer and future-proof:
func isFeatureAvailable() -> Bool {
#if BUILDING_FOR_SIMULATOR
return false
#else
return true
#endif
}
This uses the SWIFT_ACTIVE_COMPILATION_CONDITIONS build setting.
Dave DeLong:
Buried deep inside the Xcode Build Settings reference is a pair of obscure build settings: INCLUDED_SOURCE_FILE_NAMES and EXCLUDED_SOURCE_FILE_NAMES.
As their names suggest, these build settings allow you to specify additional files via your build configurations. When compiling, the exclusions happen first, and then the inclusions are applied, resulting in a final set of files passed to the compiler.
The values to these settings can be explicit paths to files, or they can be glob patterns (like *.swift). Since this is a build configuration file, substitutions work too: *.$(CURRENT_ARCH).c. And finally, since these are regular build settings, we can conditionalize the value based on the SDK.
He uses these to match platform qualifiers in the directory and filenames.
iOS Mac Programming Swift Programming Language Xcode
Tom Warren:
Google launched a new YouTube design nearly a year ago, but if you’ve been using Edge, Safari, or Firefox then you’ve probably wondered why YouTube is loading so slowly. Mozilla program manager Chris Peterson has highlighted the issue this week, and it’s not your alternative browser that’s to blame. Google’s redesign still relies on a deprecated shadow DOM API that’s only implemented in Chrome, making other browsers render YouTube five times slower.
Via Nick Heer:
The implication here seems to be that Google has built YouTube to run well specifically in Chrome because they want more people using their own browser, and that it’s somewhat anticompetitive in the vein of their blocking of other products on competing platforms. I get that angle, but I think it’s misapplied here. It seems more likely to me that Google just didn’t adequately test YouTube in non-Chrome browsers, probably because they’re less popular and maybe because they don’t care.
Google Chrome Mac macOS 10.13 High Sierra Web YouTube
Ken Kocienda (former Safari, iOS, and watchOS engineer):
I wrote a book about my Apple career. Creative Selection: Inside Apple’s Design Process During the Golden Age of Steve Jobs. It's coming out on September 4. You can pre-order today.
In the book, I tell stories about developing the original iPhone, iPad, and Safari web browser, and I give my personal view on what made the Apple product culture special.
I’ll also tell how text editing bugs are like failed birthday cake orders, and how the keyboard autocorrection algorithm for the first iPhone was like a bike lock with letters instead of numbers. Plenty more goodies too!
It has some great early reviews. I’ve pre-ordered it.
Update (2018-07-30): Matt Drance:
Respect and congrats to @kocienda on his new book. Haven’t read it, but I’m confident it’s wonderful. Noteworthy not only because Ken is credible, but because he’s broken the ice. I hope this will be the first of many insightful memoirs… “finally.”
John Gruber:
I’ve read an advance copy of the book, and for now I’ll just say this: it’s extraordinary.
Ken Kocienda:
I commissioned Guy Shield to draw 13 original illustrations for the book. To me, they're like film stills that supplement my stories. They appear as full pages in b+w. There are also forty other figures and technical illustrations throughout the text.
See also: Kocienda’s WWDC sessions: 2014, 2012, 2011, 2010.
Update (2018-08-08): Benjamin Mayo:
In this exclusive excerpt, you get a sense of how designing the iPhone software keyboard was anything but obvious. In late 2005, Apple paused all internal development on iPhone and told all engineers to invent keyboard concepts. This excerpt details how Kocienda’s winning design was shot down by Phil Schiller and Tony Fadell, which sent him back to the drawing board …
[…]
You can see from these sketches how anything was up for grabs. On the left, Ken imagined a ribbon of little letters spanning from A – Z in a small line (only the letters A and Z are included in the sketch). Tapping on this row would magnify the nearby keys in the larger section above, which could then be pressed to add that letter to the text string.
On the right, you can see early ideation of Kocienda’s plan to put multiple letters on each key. The system would try to guess which word the user actually meant to type, and a suggestion bar (ala QuickType) would let the user specifically select a completion.
Update (2018-09-04): Eric Slivka:
Once Safari launched, Kocienda shifted to a project to bring WebKit-based rich email editing to Apple’s Mail app, and he details the lengths he went to in order to make insertion point cursor placement behave properly, a feature that’s more complicated than one might think.
Following a brief stint as a manager of Apple’s Sync Services team for cloud data synchronization in which he found the job wasn’t for him, Kocienda in mid-2005 boldly threatened to quit and perhaps move to Google if he couldn’t be switched to a new role on the “new super-secret project” that was rumored within the company. He soon found himself interviewing with Scott Forstall, who invited him to join Project Purple, the effort to build the iPhone.
Update (2018-09-05): Craig Hockenberry:
This book changed my view of Scott Forstall because it gave context to his work. Ken’s account breaks down the approach and shows how important Scott’s leadership was to Apple’s success.
Having Steve Jobs as a boss for your entire professional career would not be easy, but Scott handled it with great success. Even when that powerful mentor was asking for skeuomorphism.
The hardware would be lesser without Jony, and Ken shows that the software would be lesser without Scott.
Jason Snell:
Despite the huge importance of the iPhone, I found the section about Safari and WebKit to be the most fascinating part of the book. In those days, Internet Explorer was pretty much the only browser on the Mac, and the Mac was constantly being dinged for being slow at web browsing—in other words, Microsoft was responsible for a huge portion of public perception of how good the Mac was. It simply couldn’t continue, so Jobs ordered a new browser with a premium on speed.
Fair enough, but how does one go about building a new browser? Melton, Kocienda, and team addition Richard Williamson ended up investigating open-source code bases and making the somewhat counterintuitive choice of Konqueror from the Linux desktop environment KDE. Even knowing how the story ends, I enjoyed how Kocienda tells it.
Update (2018-09-06): Ken Kocienda:
Steve didn’t write code. He didn’t design icons or graphics. He didn’t. Steve was an editor. He sent the assignments. He communicated what he wanted: “I want a software keyboard,” in this case. And then he evaluated the work that came back, right, and so he was looking for people to provide original answers for the questions that he asked. But then he’d be very, very tough as an editor.
[…]
So I feel like I owe the [Scott Forstall] a lot of debt of gratitude. But not only that — he had great taste. He was also very decisive, and he was an important part of this culture that we’ve been talking about. He helped to keep us on track, to encourage us. But he could be tough, just like Steve was, and be very, very demanding.
So we decided to err on the side of not inserting obscenities into the text that might be going to your grandma. This issue was something that we dealt with in a related context, which is hate speech. We discovered that we needed to add words that you would never say in polite speech — racial, ethnic slurs. We actually needed to research and get a compendium of these words and add them to the [iPhone] dictionary […] so that the software would never assist you in typing these words.
See also: The Creativity Cultivator Podcast.
Update (2018-09-08): See also: Triangulation, TechCrunch Disrupt.
Update (2018-09-10): Ken Kocienda:
A few people have asked me why I called my book “Creative Selection”. It’s a tip of the hat to Darwin.
My experience has taught me there are few Eureka! moments when trying to make excellent work. You can’t count on a flash of inspiration to jump you from idea to goal. However, you can use a Darwinian approach to evolve your work through round after round of refinement.
Start with an idea. Make something concrete and specific to show off that idea. Focus on incremental ways to improve. Discard the weak ideas. Reinforce the strong. Find people who can give feedback and help you edit. Evolve your work in steps. Take a page out of Darwin.
Simple to describe. Hard to do. Yet, ignoring the difficulty won’t make it go away. It’s better to face it, to get started by making something you can evaluate and improve, and then keep going. Don’t tell. Show.
See also: Oral History of Kenneth Kocienda and Richard Williamson, part 1 and part 2 (via Steve Troughton-Smith).
Update (2018-09-20): Ken Kocienda:
As I was writing my book, I told many jokes in my stories that my editor convinced me that we should cut. Some geek programmer humor is good, but keeping control on the eyerolls/minute rate is probably better.
See also: Vector, Reddit.
Update (2018-09-24): Ken Kocienda:
Here’s another geeky detail that didn’t make it into my book. A flowchart of the workflow we used to write Safari code. This details how the Page Load Test (PLT) helped us make the web browser go fast.
Update (2018-10-02): See also: Accidental Tech Podcast, The Wall Street Journal (Hacker News), Linda Dong.
Apple Book History iOS iPad iPhone Safari Scott Forstall Steve Jobs watchOS WebKit
Nick Wingfield:
The recording of that interview, which The Information and Wall Street Journal are jointly publishing for the first time, is an opportunity to hear, in vivid form, how Mr. Jobs viewed the opportunity presented by mobile software years before its success became conventional wisdom.
Juli Clover:
In the early days of the App Store, Apple was criticized for high app prices. “It’s a competition,” said Jobs. “Who knew what to price things at?” According to Jobs, Apple didn’t have advice for developers on pricing either. “Our opinions are no better than yours because this is so new.”
John Voorhees:
What can only be captured by the audio of the interview, is Jobs’ apparently sincere astonishment at the success of the App Store. In retrospect, it’s amusing to hear Jobs speculate that the App Store might someday reach $1 billion in revenue when we know now that it’s paid out a net to developers of $100 billion[…]
App Store History iOS Steve Jobs
