Josh Centers:
Overshadowed by the excitement of Apple’s latest product announcements was the loss of a long-standing Apple product. On 9 September 2014, Apple took its Web site offline briefly to slip in a redesign, new iPhone models, and the Apple Watch, but when the site returned, there was something missing: the iPod classic, which had been unceremoniously scrubbed from both the site and Apple’s online store. The 160 GB iPod classic is survived by the 2 GB iPod shuffle, the 16 GB iPod nano, and the iOS-based iPod touch.
Update (2014-09-15): Mat Honan:
In all likelihood we’re not just seeing the death of the iPod Classic, but the death of the dedicated portable music player. Now it’s all phones and apps. Everything is a camera. The single-use device is gone—and with it, the very notion of cool that it once carried. The iPhone is about as subversive as a bag of potato chips, and music doesn’t define anyone anymore.
Soon there will be no such thing as your music library. There will be no such thing as your music. We had it all wrong! Information doesn’t want to be free, it wants to be a commodity. It wants to be packaged into apps that differ only in terms of interface and pricing models. It wants to be rented.
Update (2014-10-28): AppleInsider:
Speaking with Wall Street Journal editor Gerry Baker, Cook said Apple was no longer able to source parts for the capacious iPod, which was the last of its kind to integrate a spinning hard drive for storing up to 160GB worth of music.
Kirk McElhearn:
I don’t think the choice of retiring the device was about parts. I think it no longer fits in Apple’s concept of what their devices should be like.
Update (2014-12-13): Ben Lovejoy:
Apple kept making the iPod Classic for much longer than many expected, but when it finally called time over lack of components there were still plenty of people who wanted one. The Guardian reports that some iPod Classics are now selling for up to four times the original price.
iPod Sunset
Andy Matuschak:
If classes are so much more powerful than structs, why use structs? Well, it’s exactly their limited scope that makes them such flexible building blocks. In this article, you’ll learn how structs and other value types can radically improve your code’s clarity, flexibility, and reliability.
The whole objc.io issue about Swift is good.
Language Design Programming Swift Programming Language
Ben Markowitz:
Want to get a feel for the new iPhone 6 Plus? Stack two standard checkbooks. Gets you length, width, and depth.
JesusFartedToo:
Like many of you, I’m still having trouble deciding which size to get. I put together these images that display the two models at actual size, keyboards included.
Tim Schmitz:
Both the iPad Air and the iPad mini have a “regular” size class in both dimensions, which implies that Apple is at least leaving room for something larger than the iPad. The likeliest explanation is that they’re keeping their options open for shipping larger devices in the future.
PaintCode:
The new iPhone substantially changes the way graphics are rendered on screen. We’ve made an infographic to demystify this.
[…]
iPhone 6 Plus - with Retina display HD. Scaling factor is 3 and the image is afterwards downscaled from rendered 2208 × 1242 pixels to 1920 × 1080 pixels.
Marcel Weiher:
The iPhone 6 Plus has a 1920x1080 panel, but the simulator renders at 3x. These two resolutions don’t match and so the pixels will need to be downsampled to the display resolution. Whether that is accomplished by downsampling pixel art (which happens automagically with Quartz and the proper device transform set) or as a separate step that downsamples the entire rendered framebuffer doesn’t matter (much). Either way, there are no more “pixel perfect” pre-rendered designs.
Pablo Bendersky:
3x assets and the scaling is weird. I figure it’s a stop gap measure until we can get screens at 4x resolutions, so we can go back to pixel perfect assets if we wish to. While iOS 7 and 8 have a visual style that do not require pixel perfect mockups, iOS 7 was touted as designed for retina displays, and the recommendation was to use retina assets (like 1px lines) which might not look good on the 6 Plus.
Brent Simmons:
The @3x thing makes me feel like one of those computers in the original Star Trek that Kirk destroys by feeding it bad input. Does. Not. Compute. Can’t. Divide. Three. By. Two. Help. Me.
Update (2014-09-19): Peter Bright:
Apple’s large screen iPhones seem very space inefficient. 4.7" 6 is bigger than the 5" Lumia 930. 5.5" 6+ is almost as big as 6" Lumia 1520.
Update (2014-10-10): Adam Banks and Alan Stonebridge (via Accidental Tech Podcast):
Of course, 1920x1080 happens to be the exact resolution of a Full HD movie such as those you might rent or buy from Apple’s built-in iTunes Store. Hurrah! But wait. Screen-grabbing playback in the Videos app shows that the display is still being rendered at 2208x1242. Yes, the software is actually scaling up your 1080p video (reducing its quality) so that the hardware can scale it back down (reducing its quality) to display it at 1080p. Madness.
Update (2014-10-16): Accidental Tech Podcast says that the iPhone 6 Plus does display video at native 1080p and links to an API and test video.
Graphics iOS iPad iPhone iPhone 6 iPhone 6 Plus Retina
Marcel Weiher:
About a month ago, Jesse Squires published a post titled Apples to Apples, documenting benchmark results that he
claims show Swift now with a roughly 10x performance advantage over Objective-C.
Although completely bogus,
the post was retweeted by Chris Lattner (who should know better, and was supposedly
mostly interested in highlighting the improvements in the Swift optimizer, rather than
the bogus comparison) and has now been referenced a number of times as background
knowledge as to the state of Swift. More importantly, though the actual mistake
Jesse makes is pretty basic and not that interesting, it does point to some deeper
misunderstandings about performance and language that I at least do find interesting.
[…]
A second takeaway is that the question “which language is faster” doesn’t really make sense, a more relevant and interesting question is “does this language make it hard/possible/easy to write fast code”. Objective-C lets you write really fast code, if you want to, because it has the low-level chops and an understandable performance model. Swift so far can achieve reasonable performance at times, ludicrously bad at other times (especially with the optimizer turned off, which hardly fazes Objective-C), with as far as I can tell fairly little predictability or control. Having 10% faster (or slower) performance for code I don’t particularly care about is not worth nearly as much as the knowledge that I can get the 1-5% of code that I do care about in shape no matter what. Swift is definitely not there yet, and given the direction it is taking I am not sure whether it will allow that kind of control, at least in comprehensible ways.
[…]
A third point is something more general about language. The whole argument that
NSNumber and NSArray are “built in” somehow and int is not displays a lack of
understanding of Objective-C that to me seems staggering. Even more so, the
whole idea that you must only use what comes provided with Cocoa and are not
allowed to build your own flies in the face of modern language design, throwing
us back to the times of BASIC (Cathy Doser, in the comments).
Christoffer Lernö:
Recently I discovered that our current project is seeing O(n²) compile times. While a small project compiles real fast, compile times for projects with 20.000+ lines of code will easily take a few minutes to compile. This is Swift supposedly at 1.0 with no optimizations turned on.
In other news, using Dictionary instead of NSDictionary when interfacing with ObjC code was able to incur a performance penalty of over 14000%. Yes, that’s Swift being 140 times slower than using NSDictionary.
Furthermore, putting your source code in the same or different files can give you a performance penalty of over 3000% in itself. Again, yes that is Swift being 30 times slower if you call something in a different file.
[…]
I’d like to see Swift succeed. It is certainly less bulky than Objective-C. However, when Swift becomes unworkable for projects exceeding 15.000 LOC, then no amount of liking the language is going to help. Nor will you be able to replace it with ObjC/C if you have a performance sensitive application.
Marcel Weiher on the compilation time:
1000x slower? Wow, that’s worse than I would have expected (and I expected bad). Unlikely to change significantly (see C++,Scala etc)
Expensive default semantics, 100% reliance on optimizer to get remotely reasonable perf., unpredictable performance model.
I still like the potential of Swift, but it sounds like it’s currently very easy to paint yourself into a corner. It is troubling that basic features like dictionaries are so slow.
Update (2014-09-14): Christoffer Lernö:
Since Scala is a bit infamous for slow compilation times – partly attributed to type inference – my fear has been that Swift would remain fairly slow at compilation. However, I’ve been assured that Swift’s model is much closer to that of F# and C#. The current O(n²) compiler times are due to bugs and not due to any inherent complexity in the language itself.
Cocoa Compiler iOS Language Design Mac Objective-C Optimization Programming Swift Programming Language
BeeLine Reader (via Lukas Mathis):
BeeLine Reader makes reading faster and easier by using a color gradient that guides your eyes from the end of one line to the beginning of the next. This gradient makes you less likely to skip or repeat lines, so you read faster.
It really seems to work.
BeeLine Reader Typography Web
James Dempsey:
First, we see how the user interface has evolved. The tabs begin with the natty pinstripes and bubblicious tabs of the original Aqua interface, appearing on the home page immediately after Aqua was introduced in January 2000. This was the first production use of Aqua elements by Apple—the release of Mac OS X, 10.0 was over a year away. Through the next fourteen years, we see the designs become simpler as the candy look becomes more subtle before disappearing entirely. With the removal of dividing lines between items, the original tabs have finally morphed into a simple menu bar.
This week’s update also ended the reign of Lucida Grande as the font of choice—the honor now belongs to the Apple variant of Myriad.
Apple History Web
Jeff Johnson:
If Apple is willing to give us a bigger screen on the iPhone, will they once again please ship a 17 inch MacBook Pro?
Having a larger screen on my MacBook Pro would make me much more productive. The normal 15-inch resolution just doesn’t show very much content. The 1900×1200 shows a lot, though less than my desktop setup, but it is tiring on the eyes.
When traveling, if the available Wi-Fi doesn’t block the port, I supplement with my iPad mini via Air Display (App Store). Unfortunately, there is (according to Avatron) a bug in the OS that prevents MacBook Pros from outputting at HiDPI resolutions. So Air Display can only run the iPad at full Retina resolution (way too small to read) or at a blurry 1024×768.
Air Display Bug Display iOS iOS App Mac Mac OS X 10.9 Mavericks Retina
Jonathan Zdziarski on the changes in iOS that address his reported iOS Backdoors, Attack Points, and Surveillance Mechanisms:
The file relay service is now guarded. While the service still exists, all attempts to extract data from it will fail with a permission denied error (see screenshot at the bottom of this post). Only under certain circumstances, such as beta releases and on managed devices can the file relay be activated.
[…]
Connections to a number of other services (house_arrest, afc, and others) on the device, has now finally been restricted and these mechanisms are deemed “usb only” services. Wireless clients are no longer permitted to obtain file handles to application sandboxes (only USB clients), so third party application data can no longer be dumped across WiFi. Additionally, wireless clients are not permitted to access the user’s media folder via AFC (Apple File Connection) or access certain other types of data.
[…]
Lastly, wireless access to the built-in packet sniffer (com.apple.pcapd) has been disabled, and the service has been listed with a new “usb only” descriptor, so that lockdownd will refuse to attach to it over WiFi. The packet sniffer can only be accessed while the device is connected over USB, eliminating it as a surveillance risk, while retaining its use for debugging and engineering.
[…]
While closing off the file_relay service greatly improves the data security of the device, one mechanism that hasn’t been addressed adequately is the ability to obtain a handle to application sandboxes across a USB connection, even while the device is locked. This capability is used by iTunes to access application data, but also presents a vulnerability: commercial forensics tools can (and presently do) take advantage of this mechanism to dump the third party application data from a seized device, if they have access to (or can generate) a valid pairing record with the device.
[…]
While the amount of data that can be scraped from an iOS 8 device has been greatly reduced, there is still some risk, and therefore still some steps you can, and should, take to ensure the data security of your device. When traveling through airports, or if you suspect you may be detained by law enforcement, powering down the device will cause the data-protection authentication (NSFileProtectionCompleteUntilFirstUserAuthentication) to be discarded from memory, rendering this type of attack unsuccessful, even with a valid pairing record from a desktop machine. Secondly, consider pair locking your iOS device using Apple’s Configurator tool. I have outlined instructions to do this. This will prevent an unlocked device from being able to establish a pair record with any device, other than the computer you’ve initially paired with in setting it up.
Update (2014-09-18): Andreas Kurtz:
While the iOS 8 sandbox has been revised to limit the ways in which third-party apps could surveil users, such as monitoring their texting or app usage behavior, some of the issues we reported are still present (e.g., determining installed apps, permantetely monitoring pasteboard content from within background apps, observing phone call metadata).
Apple iOS iOS 8 Law Enforcement Pasteboard Privacy Security
