I don’t see a follow button on iTunes artist pages. Maybe this is an Apple Music thing, and I can’t get to it because I don’t subscribe. On the Connect tab I might expect to see some kind of discovery mechanism, but no. Maybe I’m missing something.
As a fan I don’t feel “connected” to anything. I feel sad. Even a post from Weezer only got 13 comments, and they all looked like this […]
This experience is probably rare. Most artists will likely not lose all of their followers and data. But it only happened because of the cascade of design failures we encountered while attempting to do something any 1.0 service should offer. Every service in the world allows you to change your profile photo. Every service in the world shows you how many followers you have and gives you ways to contact them. These aren’t optional features, even for something brand new. Seven months later—from a company the size of Apple—this isn’t just unacceptable, it’s pathetic.
It’s also not a very good broadcast medium. Sure, I can post to Connect and share out to Twitter and whatnot, but why? There’s nothing unique or powerful about Apple’s system that makes it a good hub. Because I have no idea how many followers we have, I can’t even make a numerical argument for Connect-first posting. And since we can’t even invite people from other places to follow us on Connect, there’s no incentive to try.
Archive for February 2016
Although 97% of Android phones have encryption as an option, less than 35% of them actually got prompted to turn it on when they first activated the phone. Even then, not everybody chooses that extra layer of security.
A Google spokesman said that encryption is now required for all “high-performing devices” — like the Galaxy S7 — running the latest version of Android, Marshmallow. But only 1.2% of Android phones even have that version, according to Google.
By comparison, most Apple products are uniformly secure: 94% of iPhones run iOS 8 or 9, which encrypt all data.
Once I left the UK and became a permanent resident of these United States, I needed to change my iTunes account’s country so I could begin making purchases on the US store. Apple’s support article on how to complete this process makes it appear pretty straightforward, yet there are some consequences which are only briefly mentioned[…] I’ve been purchasing music, videos and apps from the iTunes and App Stores since the iTunes Store first launched in the UK back in 2004, so these seem to be pretty major consequences.
Unfortunately, this creates a paradoxical situation if I want to purchase content in the future. I now live in the US, so my payment method and billing address would only work with the US store, yet I need to remain as a UK store customer because I cannot cancel iTunes Match, effectively meaning I’ll no longer be able to purchase any iTunes or App Store content until the end of the year since I no longer have a UK billing address and payment method.
One unavoidable step in the country change is that both iTunes Match and Apple Music subscriptions had to be cancelled. This means any matched or uploaded music, as well as any music I’d saved through Apple Music (such as playlists and albums) was lost.
Now that I my purchase history starts anew, all the movies and TV shows that I’d purchased can no longer be streamed or downloaded from any of my devices.
The App Store Review 3.1 Guideline is as clear as it gets: this rejection is completely my fault.
My app doesn’t let the user generate any content: it just lets you enjoy Twitter’s content (where you can report/flag/block anything/anyone you want).
Even if I were to implement what I was asked to, Stream uses only real time data, it would be of no use to the app itself.
I like to have as little UI elements as possible: since these in-App Purchases can be “re-bought” for free, I didn’t implement a Restore button.
The reviewer (I assume, newly employed) was using an iPad and was claiming that he couldn’t pass the Twitter authorization screen: that’s the screen that shows up when you launch Stream for the first time.
The problem was not very clear because of the Reviewer’s inaccurately cropped screenshots and ambiguous messages.
Apple blacklisted their own enet driver in a silent security update, SIP prevents fixing.
This software update was pushed via the silent “security updates” to my iMac today:
031-51913 | Incompatible Kernel Extension Configuration Data 3.28.1
After rebooting my ethernet didn’t work. Turns out that it added an exclusion for the stock AppleBCM5701Ethernet driver! This breaks ethernet and you have to use WiFi to get online.
I rolled the exclusion list back to the last version in my Time Machine backup to fix it, but this required booting from a recovery partition and was a huge pain in the butt, not to mention the time wasted finding the problem.
So apparently the version of the kernel extension for the built-in ethernet driver (AppleBCM5701Ethernet.ext) in OS X 10.11.3 has been added to the blacklist by Apple (AppleKextExcludeList.kext). Specifically versions lower than 10.2.0 have been blacklisted and version 10.1.12 is the one included in OS X 10.11.3.
The blacklist is dynamically pulled by OS X (it’s not part of a system update) and I’m not sure what the trigger is exactly. The mod date on the bad AppleKextExcludeList.kext for me was Feb 24. The “good” one is from Nov 12.
This is a result of Apple’s security processes working to disable kernel extensions Apple deems harmful. Also included in this update was the banishment of spyresoft’s Dockmod which somehow managed to get a kernel extension signed by Apple into production, in conflict with the security guidelines for OS X. This is a concern for a number of reasons, but that’s a matter for another day.
Fortunately, Apple realized their error in a short period of time, and pushed another Incompatible Kernel Extension Configuration Data update which removed the entry for the Ethernet Kernel Extension.
What remains to be seen is why they released this change now as opposed to after 10.11.4 shipped and had been in the field for some time. Given the catastrophic affect on systems, though, it’s possible this was just an intern with a faulty commit button that wasn’t caught. Neither make me feel warm and fuzzy about the state of software coming from Apple.
Unfortunately, this blacklist update appears to have inadvertently contained the kernel extension information for Apple’s own Ethernet drivers. This is a problem because blocking the Ethernet drivers means your Mac will not be able to connect to your network via an Ethernet connection.
If the Ethernet drivers are blocked, but the Mac has not yet rebooted, your Ethernet connection will remain working until the next time the Mac reboots.
Affected Mac computers that are connected via wi-fi will get the update and the Ethernet adapter will be once again detected and functional. But if wi-fi is unavailable, it won’t be possible to use deployment methods such as Munki, ARD, Casper etc, or wait for automatic updates to fix the error. Manual intervention is required, either connecting via external Ethernet adapter and running software updates, or transferring the fix manually with a Flash Drive. That could be a support-time problem in organisations that have ethernet-connected Mac labs, common in education.
After this error by Apple, IT organisations may need to consider testing Apple security updates before deploying them to their Mac fleets.
If the Ethernet connection on your Mac stopped working recently, check System Information to find out which version of “Incompatible Kernel Extension Configuration Data” is installed. If you have version 3.28.1, you need an update. If you can connect to WiFi, your Mac will update to version 3.28.2 automatically, or you can follow the steps below to restore it manually.
The reason, I think, that you have to issue the software update command via Terminal to get the fix is that the Mac App Store app will not run if the Mac doesn’t have an Ethernet interface. (And, in general, all apps purchased from the Mac App Store require the Ethernet interface at launch to perform receipt validation.)
The reason that you have to reboot from the recovery partition, if you don’t have Wi-Fi, is to bypass System Integrity Protection. This lets you delete the kernel extension blocklist so that you can use the Ethernet driver to access the network and software update.
Note that Apple’s example
rm -rf command is incorrect. You should use straight quotes rather than smart quotes.
So TL;DR on the Apple #Ethernetgate event: The reason the update was sent out was to block a malicious app, Dockmod. The rest was errors.
Presumably intended for >= 10.11.4, where Yukon2/BCM driver updates appear to fix local vulnerabilities in IOUserClient interface.
Dockmod seems have shipped a valid signed kext that allowed root to bypass SIP and inject code into processes (like the Dock).
That seems to have resulted in getting their signing cert revoked, and a blacklist entry added for their existing kext.
AMP is designed to run only on smartphones — the “M” stands for “mobile”, after all — and its creators recommend serving different pages to desktop users. Why shouldn’t everyone benefit from a faster web?
Most of all, what problems does AMP solve that could not be fixed through the careful optimization of resources?
The WordPress team has followed the project and worked on its own implementation of AMP. Starting today, any website on WordPress.com now automatically supports AMP. There’s nothing to do. Self-hosted WordPress websites can also enable AMP by installing a plugin.
WordPress adding AMP support is a big deal as 25 percent of the web runs on WordPress. The AMP project is off to a good start with WordPress’s backing. All WordPress sites are now potentially AMP-enabled.
I’m still skeptical about this whole AMP thing. But if I can add support to my site, with little effort, and improve the experience for my readers, I don’t see why I wouldn’t.
You won’t be able to publish Instant Articles until your RSS feed has been approved.
That’s just what we need: the worst part of the App Store approval process applied to the web. No thanks.
I hate to say it but neither Instant Articles nor AMP are really good enough. I think we need a third standard for super-fast web pages.
In a month or two we’ll be able to give him a writing tool that gives us both what we want, because of the changes Facebook is about to make.
I want him to get exposure so his ideas can grow. But I also want people who read my blog to see it. Right now they don’t want to click on FB links.
It’s built on RSS, an open format. The RSS can be used for other purposes, such as posting to LinkedIn, Twitter, Medium or any new service that might come along. So Facebook doesn’t have an exclusive on this flow.
Summary: Facebook is using open web technology to power Instant Articles. I’m not sharing anything that isn’t already publicly documented on the Facebook developer site. People have trouble understanding this, I assume, because it seems so out of character for a big web destination like Facebook to care about the open web. It’s kind of a miracle. But there it is. The open web is about to get a real shot in the arm from a most unexpected place.
Update (2016-02-26): Kirk McElhearn:
FYI, I installed the WordPress AMP plugin, and Google tells me there are errors on more than half of my pages. Sigh.
Currently, Apple Stores allocate a fixed amount of time to each customer per Genius Bar appointment: 10 minutes for iOS devices and 15 minutes for Macs. If a customer’s issue requires more than that time amount, the customer is typically asked to book a successive appointment.
Apple has relied on this system in order to fit in as many Genius Bar appointments per day at each store and maintain a uniform experience. However, Apple has realized that not all technical support problems are the same and is preparing to officially allow for longer Genius Bar appointments.
The point is, Apple has gotten way to big and it’s now impossible for them to offer the same level of Genius Bar help that they did three years ago. If you have an Apple Plan they spend more time with you, but I never buy an Apple plan for Phone or Ipad. The system is close to being broken, again because of their success.
You could argue that a reward system with free holidays to California isn’t the same as putting staff on commission. But it kind of is: it’s giving staff an incentive to sell products. Sure, that doesn’t mean they will necessarily start applying high-pressure sales techniques, but it does mean they may be a little less inclined to spend ten minutes explaining iCloud, or pleasantly passing the time of day with a customer who has no intention of buying anything, when they could be using that time to have conversations that might win them a holiday.
You could even argue that it’s actually worse than commission, as you’re encouraging pushy sales at the same time as ensuring that only the smallest handful of staff will benefit.
You can see as the pie went from several hundred million computing devices sold each year to now almost 2 billion computing devices sold annually (when you add up PCs, tablets, and smartphones), the pie has gotten much larger but the landscape has also changed. While Android has the largest chunk of the pie, they do not have the 97% share Microsoft once had. The size of the pie and the global diversity of the consumer market brought with it the opportunity for several computing platforms to exist simultaneously.
Apple engineers have already begun developing new security measures that would make it impossible for the government to break into a locked iPhone using methods similar to those now at the center of a court fight in California, according to people close to the company and security experts.
The way the iPhone works today, when put into recovery mode you can restore the operating system without entering the device passcode. The only restriction is that the version of iOS to be installed must be properly signed by Apple.
I think what Apple is leaking here is that they’re going to change this (perhaps as soon as this year’s new iPhone 7), so that you can’t install a new version of iOS, even in recovery mode, without entering the device’s passcode. (I think they will also do the same for firmware updates to the code that executes on the Secure Enclave — it will require a passcode lock.)
If you do a full restore, you can install a new version of the OS without the passcode, but this wipes the data.
It’s understandable that Tim Cook wants the conversation to be about the FBI asking Apple to build a backdoor. But I think a more accurate description is that the backdoor already exists. Apple today could update the OS to remove security protections, without wiping the data. The dispute with the FBI is that Apple doesn’t want to use the backdoor. And now it is working to remove it.
Previously: FBI Asks Apple for Secure Golden Key.
So when Apple says the FBI is trying to “force us to build a backdoor into our products,” what they are really saying is that the FBI is trying to force them to use a backdoor which already exists in their products. (The fact that the FBI is also asking them to write new software is not as relevant, because they could pay somebody else to do that. The thing that Apple can provide which nobody else can is the signature.)
Is it reasonable to describe these single points of failure as backdoors? I think many people might argue that industry-standard systems for ensuring software update authenticity do not qualify as backdoors, perhaps because their existence is not secret or hidden in any way. But in the present Apple case where they are themselves using the word “backdoor,” abusing their cryptographic single point of failure is precisely what the FBI is demanding.
Update (2016-03-03): Alexis Gallagher:
Part of Apple’s defense rests on the fact that they don’t have the passcode, and the FBI is ordering them to create new software. […] What happens to Apple’s legal position if the FBI “only” orders Apple to hand over the signing keys (poor man’s passcode)?
Privacy is definitely one reason to use local backups; if your encrypted phone backup is stored on your encrypted laptop that is itself protected with a strong password, there’s very little chance that anyone without the right credentials can get access to anything.
There are also benefits when you’re restoring that backup to your iPhone. As Apple’s page on encrypted iTunes backups outlines, encrypted local backups are the only ones that contain saved account passwords, Wi-Fi settings, browsing history, and data from the Health app. Apple doesn’t want this data on its servers for security and privacy reasons, and it’s not stored in unencrypted local backups for the same reason. Use encrypted local backups, and you get that info back if you need to do a restore.
It also helps if you’re upgrading to a new phone or using a loaner or replacement phone. When you restore an iCloud backup to a phone or tablet that’s not the phone or tablet you backed it up from, you don’t lose any of your photos or iMessage history or anything like that, but you do lose the credentials for e-mail accounts and any other apps that require authentication.
An archived iTunes backup is essential because it saves the current state of your iOS device and prevents it from being accidentally overwritten by subsequent backups. Apple recommends all public beta testers create an archived backup before installing a beta in case something goes wrong and a restore is needed.
To archive the backup, choose “Preferences” from the iTunes menu and select the “Devices” tab. Choose the fresh backup and right click to bring up the “Archive” option.
Update (2016-02-25): I have been informed that iCloud backups do include this extra data. Apple says they are encrypted, but I think this is on disk and in transit—not encrypted from Apple, who we know can access the data because it provides it to law enforcement. So it’s on the level of Dropbox’s encryption.
Update (2016-03-03): Juli Clover:
The details surrounding the case have made it clear that while Apple is unable to access information on iOS devices, the same is not true of iCloud backups. Apple can decrypt an iCloud backup and provide the information to authorities when ordered to do so via a warrant, as it did in the San Bernardino case.
In a piece posted on The Verge entitled “The iCloud Loophole,” Walt Mossberg takes a look at Apple’s iCloud backups and explains the reason why iCloud data can’t be made as secure as data stored solely on an iPhone or iPad.
The default iOS setting for iPhones is for message alerts to chime with the text tone twice, in a two minute interval. While the repeat text message alert sounds, notifications, and vibrations on the iPhone can be helpful for some people, those of us who are basically glued to our phones tend to experience quite the opposite and end up finding the repetitive alerts a nuisance, since it can seem like you’re being inundated with texts when you’re not.
Multiple chimes/buzzes for iMessage have been annoying me for years. I thought this was a bug, but it turns out that the notification settings for Messages are different from the settings for other apps.
I’m having trouble with a core data many-to-many relationship where both side’s delete rules are set to Nullify. I’m finding when I inspect the SQL database there are records left in the join table that should be deleted.
The two tables represent Playlists and Tracks. Playlist deletes don’t cascade to delete each track automatically because each track can be in multiple playlists.
I’ve noticed if you delete the relationship i.e. using removePlaylistTracksObject:, then save, then delete the playlist and track, then save, it works. I would expect the relationship record to be removed when deleting either the playlist or track and a single save. Also if the playlist to tracks is not ordered it works fine.
Thanks for the test case, that is an actual issue in Core Data. There is nothing in there that you are doing incorrectly. You really need to file a radar on this and I will file one as well.
In the interim you can either stop using ordered relationships (they are a bastardization anyway) or do the double delete.
Previously: Core Data Bugs.
Update (2016-02-25): James O’Leary:
Every year for (x) years I think “I should get rid of my ordering hack”, do research, and find CD’s is still broken :(
A frequent complaint with Auto Layout is how verbose and unreadable the syntax is for programmatically creating constraints. Fortunately iOS 9 has done a lot to improve things. Stack Views have removed the need for us to create many of the constraints in typical layouts. Overlooked by comparison, but just as useful, was the introduction of layout anchors and layout guides. From the Apple Auto Layout Guide […] I will look at layout guides another time but for now here are my notes on using layout anchors to create constraints in code without the pain.
Every line of code written comes at a price: maintenance. To avoid paying for a lot of code, we build reusable software. The problem with code re-use is that it gets in the way of changing your mind later on.
If we see ‘lines of code’ as ‘lines spent’, then when we delete lines of code, we are lowering the cost of maintenance. Instead of building re-usable software, we should try to build disposable software.
logGen can be used to detect what files have changed as a result of a configuration change or installing a package. It accomplishes this by utilizing a number of methods, but mostly using the modification date and a checksum of each file. Lists will be generated for files that are added, changed, or deleted, and will include only the directory if everything within it has been added, changed, or deleted. A number of directories are automatically ignored in the search including your home directory, temporary directories, network mounts, and non-root volumes.
Over the course of the iOS 9.3 beta testing period, iPad Pro users running the update have noticed a disturbing feature removal that limits the functionality of the Apple Pencil. In the current version of iOS, iOS 9.2, the Apple Pencil can be used for navigational purposes, just like a finger. It’s possible to tap on buttons, select text, scroll, swipe between apps, access menus, and access general editing controls in non-drawing apps.
With iOS 9.3, much of that functionality has been removed. The Apple Pencil is no longer able to be used for selecting and manipulating text or doing things like scrolling -- it’s only available for selecting buttons and drawing, sketching, and writing within apps.
But the fact remains that the Pencil’s owners use those navigation options, and frankly, the idea that Apple would take away functionality that people have come to expect and depend on is a significant hit to usability and overall experience.
Worse, it makes the Pencil useless for video and audio editing, creative pursuits that I’d hoped to explore further on the iPad Pro. I’d initially enjoyed editing and cutting several videos in iMovie for iOS with the help of the Pencil; now, you can only select and drag clips. You can’t cut a clip with the downward swipe gesture, nor can you scroll the timeline.
Being able to control the interface and manipulate text with the pencil was one of my favorite features of the iPad Pro.
Update (2016-02-22): Jonathan Deutsch:
@cgpgrey passionately discusses this on cortex and how the pencil helps his RSI (starting at 1:20:30)
Apple has no plans to cripple its Pencil accessory for the iPad Pro. After recent iOS 9.3 betas removed the ability to navigate around iOS with the $99 add-on — marketed as a drawing tool more than a stylus — Apple has confirmed with The Verge that all of those features will soon make a comeback. “We believe a finger will always be the primary way users navigate on an iPad, but we understand that some customers like to use Apple Pencil for this as well,” a spokesperson said. “We will add this functionality back in the next beta of iOS 9.3.”
Whether Apple was always intending to bring that feature back, or changed course because of the feedback it received during the beta, is an open question. If Apple truly did change course because of customer feedback, though, I see no need for the company to hide it: Listening to customer feedback and modifying your plans accordingly should be a badge of honor, not shame.
ZergHelper appears to have gotten by Apple’s app review process by performing different behaviors for users from different physical locations on earth. For users outside of China, it would act as what it claimed: an English studying app. However, when accessing the app from China, its real features would appear.
The app was made available in the App Store on October 30, 2015. However, nobody appeared to have noticed ZergHelper’s hidden functionality until February 19, 2016, when a user created a post in V2EX (a Chinese developer forum) to discuss it. We shared our findings with Apple on February 19, and Apple removed the app from the App Store later that day.
ZergHelper’s main functionality appeared to be to provide another App Store that includes pirated and cracked iOS apps and games. The app was developed by a company in China that named its main product “XY Helper”. ZergHelper was the non-jailbroken and “official App Store” version of this product.
If you find yourself needing to do anything else to read a preference, you should take a step back and reconsider: caching values from NSUserDefaults is usually unnecessary, since it’s extremely fast to read from. Calling
-synchronizebefore reading a value is always unnecessary. Responding when the value changes is almost always unnecessary, since the nature of “settings” is that they control what a program does when it does it, rather than actually causing it to do something. Having an alternate code path for “no value set” is also generally unnecessary, as you can provide a default value instead (see Providing Default Values below).
You can call
-registerDefaults:as many times as you like, and it will combine the dictionaries that you pass it, which means you can keep registration of settings near the code that cares about them.
I used to use
-registerDefaults: more, but now I mostly use a category method like:
- (id)mjtObjectForKey:(NSString *)key defaultValue:(id)defaultValue;
nil. This is more convenient (one line of code) and makes it impossible to look up a key that has not been registered.
In the sandboxed world of modern OSX and all iOS versions, NSUserDefaults is initially limited to operating in your app’s sandbox; if you use
-initWithSuiteName:you’ll just get a new store of user defaults that’s still not shared.
NSUserDefaults does not have any form of transaction system, so there’s no way to guarantee that multiple changes will only be seen all at once. Another program could see the first change before the second finishes.
NSUserDefaultsDidChangeNotificationnor KVO notify of changes made by other programs
-registerDefaults:operates on every
NSUserDefaultsinstance, not just the one you call it on
Update (2016-02-22): One of the issues I’ve found is that, starting with Mac OS X 10.10,
NSUserDefaults ignores any attempt to set an object that is a dictionary or array bridged from Python.
Orders including $25 or more of eligible books qualify for FREE Shipping. All orders of $49 or more of eligible items across any product category also qualify for FREE Shipping. With free shipping, your order will be delivered 5-8 business days after all of your items are available to ship, including pre-order items.
Previously it was $35, and it was $25 before that. However, the delivery time has been reduced from 9 business days to 8.
Looking at Apple this way gives the impression that the company has a large number (nearly a billion) of repeat (subscribed to service) customers. These customers can be seen to spend a predictable recurring amount (average selling price) on Apple’s brand. The repetition of these metrics in public commentary suggests that customer acquisition and retention are among Apple’s goals.
Seen this way each centralized resource allocation question can be assumed to be prefaced with “In order to create/preserve customers should we…?”
This leads to answers quite different from questions that start with “In order to sell/profit more should we…?”
For instance, offering education products, retail store experiences, healthcare products, green energy initiatives, accessories, content and services make sense even if they may have poor financial “returns”. These initiatives score highly on customer retention and satisfaction. They may lead to engagement and repeat sales.
Each iOS CPU is built with a 256-bit unique identifier or UID. This UID is burned into the hardware and not stored anywhere else. The UID is not only inaccessible to the outside world, but it’s inaccessible even to the software running at the highest privilege levels on the CPU. Instead, the CPU contains a hardware AES encryption engine, and the only way the UID can be accessed by the hardware is by loading it into the AES engine as a key and using it to encrypt or decrypt data.
Apple uses this hardware to entangle the user’s passcode with the device. By setting the device’s UID as the AES key and then encrypting the passcode, the result is a random-looking bunch of data which can’t be recreated anywhere else, since it depends on both the user’s passcode and the secret, unreadable, device-specific UID.
The Secure Enclave contains its own UID and hardware AES engine. The passcode verification process takes place here, separated from the rest of the system.
The escalating delays for failed passcode attempts are enforced by the Secure Enclave. The main CPU merely submits passcodes and receives the results. The Secure Enclave performs the checks, and if there have been too many failures it will delay performing those checks. The main CPU can’t speed things along.
This would be fairly easy to implement, and shouldn’t affect the usability of the device. Given Apple’s public stance on user privacy, I would find it extremely weird if it the Secure Enclave’s software update mechanism wasn’t implemented in this way. On the other hand, Tim Cook’s public letter implies that all iPhone models are potentially vulnerable, so perhaps they haven’t taken this extra step.
Previously: FBI Asks Apple for Secure Golden Key.
Alexis Gallagher gave a great conference talk about Swift protocols with associated types, which he calls PATs. They are very weird compared with regular protocols in Swift or Objective-C, and he explains why that is and why they don’t use generic protocol syntax.
Previously: Swift Protocols.
As you watch the churn in the Swift language and the many source-incompatible changes, remember stories like this.
Dennis Ritchie, on C:
In retrospect it would have been better to go ahead and change the precedence of
&to higher than
==but it seemed safer just to split
&past an existing operator. (After all, we had several hundred kilobytes of source code, and maybe 3 installations....)
Why the tab in column 1? Yacc was new, Lex was brand new. I hadn’t tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn’t want to screw up my embedded base. The rest, sadly, is history.
Languages last a long time. Even multiple years into their existence is not “too late” to change things for the better.
Not much consideration given to path dependence; “the … equilibrium achieved depends partly on the process of getting there”
Simple example; unstable languages mean unstable libraries. Ecosystems and culture build up around and optimize for that problem.
The latest data from research firm TrendForce shows that MacBook sales continue to gain momentum in an otherwise declining notebook market. Apple passed Asus and Acer to become the fourth-largest notebook maker in 2015, reaching 10.34 percent market share compared to 9.3 percent market share in 2014. Overall notebook shipments in 2015 were 164.4 million, down 6.3 percent from 175.5 million in 2014.
HP and Lenovo continued to lead the notebook industry in 2015 with around 20% market share each, but Apple is now within striking distance of Dell for third place.
Srouji runs what is probably the most important and least understood division inside the world’s most profitable company. Since 2010, when his team produced the A4 chip for the original iPad, Apple has immersed itself in the costly and complex science of silicon. It develops specialized microprocessors as a way to distinguish its products from the competition. The Apple-designed circuits allow the company to customize products to perfectly match the features of its software, while tightly controlling the critical trade-off between speed and battery consumption. Among the components on its chip (technically called a “system on a chip,” or SOC) are an image signal processor and a storage controller, which let Apple tailor useful functions for taking and storing photos, such as the rapid-fire “burst mode” introduced with the iPhone 5s. Engineers and designers can work on features like that years in advance without prematurely notifying vendors—especially Samsung, which manufactures many of Apple’s chips.
A former Apple engineer who worked on the [original iPhone] said that while the handset was a breakthrough technology, it was limited because it pieced together components from different vendors, including elements from a Samsung chip used in DVD players. “Steve came to the conclusion that the only way for Apple to really differentiate and deliver something truly unique and truly great, you have to own your own silicon,” Srouji says. “You have to control and own it.”
Say you then launch Videos and stream a five-gigabyte movie that was purchased on the iTunes Store.
The reported storage usage for the Videos app in Settings won’t increase at all.
But if you glance at the amount of free device storage reported in Settings, you’ll notice it has dropped by five gigabytes due to that streamed video being cached automatically by iOS, thereby taking up five gigabytes of ‘Other’ storage.
Because the amount of device storage wasted on the ‘Other’ category cannot be directly checked out in iOS, less experienced users may be left scratching their head, puzzled as to why their reported free storage isn’t higher.
The 291-megabyte difference between the 856MB seen in desktop iTunes and 565MB reported by my iPhone is actually caches for the songs I had streamed via Apple Music.
People who use iCloud Photo Library with the ‘Optimize iPhone Storage’ option may observe a similar discrepancy in the ‘Photos’ storage section between iTunes and iOS Settings, due to large caches of photos in device-optimized resolution.
In the electronics recycling business, the benchmark is to try to collect and recycle 70 percent, by weight, of the devices produced seven years earlier. Jackson says Apple exceeds that, typically reaching 85 percent, including recycling some non-Apple products that customers bring in.
Apple shreds its devices to avoid having fake Apple products appearing on the secondary market, Jackson said. The company is working on ways to reuse components in the future, she said, declining to elaborate.
Added better error checking in the incoming email handling code to remove the possibility of losing a message under rare circumstances
I hit this particular bug many times, so hopefully it’s fixed now. I’m still seeing problems with missing e-mail text.
Update (2016-02-22): After e-mailing with Fog Creek, it turns out that the release notes were misleading, and this release did in fact fix the bug with missing e-mail text.
When the FBI has requested data that’s in our possession, we have provided it. Apple complies with valid subpoenas and search warrants, as we have in the San Bernardino case. We have also made Apple engineers available to advise the FBI, and we’ve offered our best ideas on a number of investigative options at their disposal.
We have great respect for the professionals at the FBI, and we believe their intentions are good. Up to this point, we have done everything that is both within our power and within the law to help them. But now the U.S. government has asked us for something we simply do not have, and something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone.
Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation. In the wrong hands, this software — which does not exist today — would have the potential to unlock any iPhone in someone’s physical possession.
This is really important. Apple cannot decrypt locked phones, so the FBI wants Apple to give them a rewritten iOS that bypasses security.
I have no idea why the FBI wants in the iPhone other than to set a precedent. They already have iCloud data and text messages and computers.
I figured the FBI is just using this case as a way to get support for the public for backdoors.
Because there is nothing the data on the iPhone can tell the FBI that the FBI doesn’t know already.
What’s important to remember is that Apple gave the FBI access to everything that exists and additional advice.
Apple gave the FBI forensic advice. That fact alone makes this look even more like a backdoor fishing expedition by the FBI.
FBI Supervisory Special Agent Christopher Pluhar stated in a declaration that he was able to obtain from Apple all the data backed up to its iCloud servers from the phone. That data showed that Farook was in communication with individuals who were later killed. Significantly, Pluhar said, the most recent backup took place on Oct. 19, 2015, indicating that Farook may have intentionally disabled the backup feature.
Previously: Secure Golden Key.
If the San Bernardino gunmen had used an iPhone with the Secure Enclave, then there is little to nothing that Apple or the FBI could have done to guess the passcode. However, since the iPhone 5C lacks a Secure Enclave, nearly all of the passcode protections are implemented in software by the iOS operating system and, therefore, replaceable by a firmware update.
If you take Tim Cook’s message at face value, the ability to create such an iOS version means there already is a backdoor.
Apple seems to be evading the admission that they already hold privileged keys they can legally be compelled to use.
Essentially, the government is asking Apple to create a master key so that it can open a single phone. And once that master key is created, we’re certain that our government will ask for it again and again, for other phones, and turn this power against any software or device that has the audacity to offer strong security.
This is just the beginning. I’m sure Apple will get dragged through the mud by officers and politicians alike in the coming weeks, months, years. What will be remembered though is that this thrusts the privacy debate into the spotlight, and history will remember Apple as a leader in maintaining freedom when others would seek to erode it.
Specifically, Apple is not being asked to break the encryption on the iPhone in question (which is impossible — more on this in a moment), but rather to disable the functionality that wipes the memory when multiple wrong passcodes are entered in a row.
It’s important to be clear on the definition of backdoor: Cook is taking a broader one which says that any explicitly created means to circumvent security is a backdoor; the reason the distinction matters is that a more narrow definition that says a backdoor is a way to bypass encryption specifically would not apply here. In other words, Apple is not being asked to create a “secret key” for the data (which would be impossible after the fact) but rather to make it easier to brute force the passcode on the device.
I commend Apple for standing up to this, but unfortunately, I suspect they’re eventually going to lose.
This isn’t even REALLY about crypto. It’s about whether developers can be conscripted to write spyware.
This is an unprecedented, unwise, and unlawful move by the government. The Constitution does not permit the government to force companies to hack into their customers’ devices.
The actual order specifying the not-a-crypto-backdoor the court is requesting from Apple.
Preventing such an escape would be made all the harder by the fact that foreign intelligence agencies and criminal organizations alike would undoubtedly pay immense sums of money for access to such a master key. A security exploit broker called Zerodium already paid $1,000,000 for a browser-based security exploit in iOS 9 that it planned to resell to government and defense customers (see “The Million Dollar iOS Hack (Isn’t),” 3 November 2015). And that’s for something that Apple probably found and blocked in one of the updates to iOS 9. Can you imagine how much an iOS master key would sell for? And how that kind of money could corrupt people within the chain of trust for such a key? Like Tolkien’s One Ring, the power of a master key for millions of phones would be nigh-impossible to resist (unfortunately, Apple’s latest diversity report didn’t break out the number of courageous hobbits working at the company).
That’s why this is about far more than a single phone. Apple does not have the existing capability to assist the FBI. The FBI engineered a case where the perpetrators are already dead, but emotions are charged. And the law cited is under active legal debate within the federal courts.
The crux of the issue is should companies be required to build security circumvention technologies to expose their own customers? Not “assist law enforcement with existing tools,” but “build new tools.”
Reading through the order, it seems the FBI thinks that a modified version of the operating system would allow them to engage in high-speed attacks, if the 10-tries limit was removed. The request indicates they likely can’t image the device and perform all the attacks on their own super-fast computers, due to that hardware key. With a four-character passcode the device could probably be cracked in hours.
Without strong encryption, foreign courts and foreign bureaucracies will have access to information on American citizens living on American soil. Is that what you want, Mr. or Ms. Legislator?
It is my understanding, from background sources, that all devices are vulnerable.
Some may see this confrontation between Apple and the FBI as an industry vs. government dispute, but it’s far more than that. As personal technology and the internet permeate almost every aspect of wider society, the “tech industry” is indistinguishable from society as a whole. The right to defend our personal information, and the rights of companies to act on our behalf in that pursuit, are completely and inexorably tied to our rights as members of society.
Google CEO Sundar Pichai has chimed in on the escalating battle between the FBI and Apple over iPhone encryption. Describing the letter published by Apple’s Tim Cook as “important,” Pichai says that a judge’s order forcing Apple to assist the FBI in gaining access to the data on a terrorist’s iPhone “could be a troubling precedent.” Seeing as Google oversees the Android operating system, Pichai is a crucial voice in this debate; Android also offers encryption to safeguard personal data.
Could Pichai’s response be any more lukewarm? He’s not really taking a stand, and the things he’s posing as questions aren’t actually in question. I’m glad he chimed in at all, and that he seems to be leaning toward Apple’s side, but this could be a lot stronger.
But in addition to whatever risks government access poses, there is a subtle but crucial point that is often overlooked: The kinds of security architectures in which it is easy to insert a back door are typically less secure than the security architectures in which it is hard to insert a back door.
The point is that the FBI is asking Apple to crack its own safe, it doesn’t matter how good the locks are if you modify them to be weak after installing them. And once the precedent is set then the opportunity is there for similar requests to be made of all billion or so active iOS devices. Hence the importance of this fight for Apple.
This is the most important tech case in a decade.
I am convinced that Apple is doing the morally correct thing here, by fighting the court order. I’ll bet most of you reading this agree. But like Thompson, I’m not sure at all Apple is doing the right thing politically.
I have always admired Tim Cook for his stance on privacy and Apple’s efforts to protect user data and couldn’t agree more with everything said in their Customer Letter today.
Update (2016-02-18): Will Strafach:
On a technical level, Apple could carry out the order by creating a RAM disk signed by the company’s production certificate for the specific ECID of the suspect’s iPhone. This solution would allow Apple to use existing technologies in the firmware file format to grant access to the phone ensuring that there is no possible way the same solution would work on another device.
The aspect that would actually affect the public is the fact that by doing this, Apple will show that breaking into an iPhone is “possible,” and allow the FBI to use this case in the future as leverage.
This is only possible on a technical level in very specific circumstances, but if Apple assists in this instance, then it paves the way for more unreasonable and technically difficult requests to be made. In those scenarios, it will be on Apple to try to explain why it cannot accommodate the new requests.
To allow restoration to a custom firmware, Apple would need to either: (a) make changes to the way its restore server works for this specific case, potentially causing major security concerns if any sort of mistake is made (which could make this an unreasonable / burdensome request, or (b) bring the device onto its internal network and load the firmware using the restore server used internally, since it can be assumed that such an in-house server exists for the purpose of restoring to unreleased firmware versions.
Lost in the noise today is this terrifying detail: Apple can update the Secure Enclave without wiping the data on it.
Here’s why the totality of what we know right now leans in favor of Cook and his slippery slope argument.
The issue is not Apple’s. It is not even the FBI’s. The issue is that as often happens, technology speeds past our ability to adapt or create new laws that match the onslaught of daily technological change. Typically, I am for fewer laws rather than more, but I’m also pragmatic. We should be asking our lawmakers to enact a law that fits the need of this situation and situations like this so rather than being on an eternally slippery slope of privacy violations hidden behind the All Writs Act, we have a law that will truly limit the circumstances where companies like Apple can be compelled to help a government agency crack a device.
Rogers’ claims about Paris contradict the information that came out of France following the attacks. There were claims by former US intelligence officials that encrypted communications had been used by the Islamic State affiliated terrorists in the immediate wake of the attacks. But those claims were largely dismissed by French authorities when they looked at the actual communications on devices recovered from the group. According to statements from French law enforcement, the attackers had used standard SMS messages to communicate—not encrypted messaging apps on smartphones.
The problem is that you’re talking about a multinational organisation attempting to run a global business then needing to get picky about who can exploit weaknesses deliberately designed into the product. It’s a very slippery slope once there is a backdoor. Without it, life is much simpler – nobody gets in – and clearly this is where Apple wants to be.
The order is pretty specific technically. This implies to me that what the FBI is asking for is technically possible, and even that Apple assisted in the wording so that the case could be about the legal issues and not the technical ones.
Today I walked by a television showing CNN. The sound was off, but I saw an aerial scene which I presume was from San Bernardino, and the words “Apple privacy vs. national security.” If that’s the framing, we lose. I would have preferred to see “National security vs. FBI access.”
Apple sent trusted engineers to try that method, the executives said, but they were unable to do it. It was then that they discovered that the Apple ID password associated with the iPhone had been changed. […] Had that password not been changed, the executives said, the government would not need to demand the company create a “backdoor” to access the iPhone[…]
Update (2016-02-20): John Gruber:
Daniel Roberts has posted a screenshot of the entire segment on China that was cut from the article.
This seems like a rather important discussion topic. It’s perplexing why the Times would choose to remove it; doubly so considering it’s a silent edit. This article apparently appeared on page A1 of the print edition today, too.
A county representative later told Reuters that FBI agents requested the iCloud password reset.
Specifically, the FBI asked someone to destroy potential evidence (the iCloud auth token) that could have been used without a new backdoor.
So, technically speaking, I think what happens next is that Apple begins to engineer phones such that they can no longer assist the FBI, even if compelled by court order. Here’s my specific bet: right now Apple can update a phone’s entire software stack to reconfigure a particular phone’s behavior, including number of PIN tries and delays – the most secure parts of the phone. I bet Apple will move towards making the most sensitive parts of that stack updatable only in very specific conditions[…]
Crucial details in the @FBI v. #Apple case are being obscured by officials. Skepticism here is fair.
What many haven’t considered is the significant difference – in the legal world – between providing lab services and developing what the courts will consider an instrument.
If evidence from a device ever leads to a case in a court room, the defense attorney will (and should) request a copy of the tool to have independent third party verification performed, at which point the software will need to be made to work on another set of test devices. Apple will need to work with defense experts to instruct them on how to use the tool to provide predictable and consistent results.
Update (2016-02-22): John Gruber:
The only possible explanations for this are incompetence or dishonesty on the part of the FBI. Incompetence, if they didn’t realize that resetting the Apple ID password could prevent the iPhone from backing up to iCloud. Dishonesty, if they directed the county to do this knowing the repercussions, with the goal of setting up this fight to force Apple to create a back door for them in iOS. I’m not sure which to believe at this point. I’d like to know exactly when this directive to reset the Apple ID password was given — ” in the hours after the attack” leaves a lot of wiggle room.
When the consumer version of the Internet of Things (IoT) is broadly deployed on smart connected objects everywhere, we’ll see an astounding flow of private data. Naturally, conscientious suppliers will protect these most intimate details of our daily lives with encryption…but government busybodies will want to know if we’re following the Law as we fish, swim, eat, smoke, multiply, and die.
The San Bernardino litigation isn’t about trying to set a precedent or send any kind of message. It is about the victims and justice. Fourteen people were slaughtered and many more had their lives and bodies ruined. We owe them a thorough and professional investigation under law.
Apple has posted a FAQ:
Yes, it is certainly possible to create an entirely new operating system to undermine our security features as the government wants. But it’s something we believe is too dangerous to do. The only way to guarantee that such a powerful tool isn’t abused and doesn’t fall into the wrong hands is to never create it.
I agree, but I wish Apple wouldn’t exaggerate with language like “entirely new operating system.”
The FBI has made statements both in their court filings and in the press which are simply untrue. If it weren’t for the fact that the people making these claims are actual forensics experts (or work with such experts), I’d be inclined to say that they just don’t know what they’re talking about. Given that they do work for the FBI, I think it’s reasonable to hold them to a much higher standard of clueful-ness.
Apple is dangerously muddling the encryption debate by claiming a backdoor doesn’t exist until a proof-of-concept exploit is written.
It confuses me how much uptake this has had. Lots of people repeating it. The backdoor is there now….
Update (2016-02-23): Ben Thompson:
The first thing to understand about the issue at hand is that there are three separate debates going on: the issue at hand, the encryption debate, and the PR battle. To understand the issue it is necessary to separate them, but to figure out which side may win it is equally critical to understand how they relate to each other.
The U.S. Department of Justice is pursuing additional court orders that would force Apple to help federal investigators extract data from twelve other encrypted iPhones that may contain crime-related evidence, according to The Wall Street Journal.
Update (2016-02-28): Ted Goranson:
The FBI’s request signals a new attempt at control. This is an organization that usually delivers its requests under seal, meaning they remain secret. In this case, the FBI took the unusual step of making its demand public, so as to push the issue into the press by hitting the hot button of “terrorism.” The FBI’s intent, it seems, is to prompt lawmakers to respond to public outrage.
Most legal arguments against “unlocking” this particular phone cite the constitutionally protected right to free speech. But a better parallel is the right to gun ownership in the US and the constitutional provisions that support it. In the past, technology in the US was primarily developed in a military context and justified in the service of war, but also to maintain civil order. At the end of the eighteenth century, the apotheosis of that technology was the firearm.
Today’s most powerful technologies relate to information concerning our thoughts, associations, and bodies. If the framers of the US Constitution were alive today and as well educated as they were then, the Bill of Rights would likely be focused on balancing access to information to ensure that the government remains within bounds.
I can’t really believe that the FBI would abuse the White House’s trust by launching an unauthorized expedition to force Apple to backdoor the iPhone. To the contrary, I think this operation was vetted at the highest level – but not for its apparent purpose.
Just this morning, the NY Times tells us that a meeting last month between White House staff and tech executives ended on a sour note. (Such stories are a part of a long tradition of “authorized” disclosures, articles based on trusted relationships between insider sources and writers.) Apparently, Chief of Staff Denis R. McDonough took exception to Cook’s reproaching the White House for “lacking leadership” on the encryption issue, and reportedly called Cook’s statements a “rant”.
Update (2016-03-11): Cyrus Farivar:
As expected, federal prosecutors filed their formal response on Thursday in the ongoing case involving the seized iPhone 5C that was used by one of the shooters in the San Bernardino terrorist attack in December 2015.
Apple was surprised last month when the DOJ decided to fight this in public. But until today, the tone has been civil. Adversarial, clearly — there is no middle ground. But civil. Today, though, the DOJ made things nasty. I think Apple was genuinely surprised by the threatening tone and nature of today’s brief.
“The evidence on Farook’s iCloud account suggests that he had already changed his iCloud password himself on October 22, 2015—shortly after the last backup—and that the autobackup feature was disabled. A forced backup of Farook’s iPhone was never going to be successful, and the decision to obtain whatever iCloud evidence was immediately available via the password change was the reasoned decision of experienced FBI agents investigating a deadly terrorist conspiracy,” the government claims.
Update (2016-03-23): John Gruber:
I get the feeling the FBI concluded they were going to lose, so they’re not even going to test it.
Israeli mobile software developer Cellebrite is helping the FBI in its attempt to unlock the iPhone at the center of the San Bernardino shooter investigation.
On Monday, the U.S. Justice Department convinced the court overseeing its ongoing battle with Apple to postpone a hearing scheduled to take place March 22. The DoJ said new leads had been discovered that could provide it with a way to unlock the iPhone 5c used by San Bernardino shooter Syed Farook without involving Apple.
That was nearly twelve years ago. The person in charge of sales at that time, Tim Cook. I am sure that given what I have seen since then, I would never keep any personal files on a company computer.
So please pardon me if I am a little skeptical of Apple’s interest in preserving the privacy of anyone. The sincerest held belief at Apple is making money from selling products. That’s is fine, I have nothing against Apple making money because they make some very good products and I use one daily. However, let us not put Apple on a security pedestal without asking Tim if he would try to break into an iPhone if they thought someone at Apple was saying something the company didn’t want said.
Update (2016-03-25): Bruce Schneier:
My guess is that it’s not [Cellebrite]. They have an existing and ongoing relationship with the FBI. If they could crack the phone, they would have done it months ago.
Cellebrite, the mobile forensics company reportedly assisting the FBI to extract data from the iPhone in the San Bernardino case, has written a white paper noting that extracting the data is only part of the challenge. If law enforcement agencies are to be able to obtain convictions on the basis of that data, there are a lot of questions that have to be answered.
Update (2016-03-30): David Sparks:
The best case scenario at the legislative end would be for a law to be passed restricting access and prohibiting the government from requiring backdoors in cellular phones. Let’s just say I’m not holding my breath for that one. In my opinion if there is going to be a law passed, it’s going to be a law requiring installation of a backdoor and not the opposite.
I believe our President understands all of this, that he believes unbreakable cryptography is the lesser of two bad choices…but he must weigh what he says. Can we really expect him to say that the FBI is wrong? Instead, he lets the FBI push hard, absorbs some of the reflected Law and Order sunshine, and allows the San Bernardino case to take the long, arduous road to the Supreme Court. And Backdoor legislation will be introduced, discussed and discussed, with the Tech Industry up in arms – and dollars – against it.
By then, Barack Obama will be a former President, Free At Last to say what he really thinks. I can’t wait.
The New York Times is reporting that the outside party engaged to unlock the San Bernardino terrorist’s iPhone has been successful, and the Department of Justice is withdrawing from its legal action against Apple.
Apple has issued a statement concerning the Department of Justice withdrawing its demand under the All Writs Act that the company aid in creating a version of iOS that would be faster and easier for the government to hack into.
I guarantee you at some point, somebody told Director Comey, “good god, Jim, you’ve got to make this go away.”
A battle is over, but the war has only just begun.
Update (2016-04-02): Jonathan Ździarski:
FBI: You should do it, it’s just one phone
Apple: No it isn’t
FBI: We got in
Apple: You should say how, it’s just one phone
FBI: No it isn’t
The FBI cracked a San Bernardino terrorist’s phone with the help of professional hackers who discovered and brought to the bureau at least one previously unknown software flaw, according to people familiar with the matter.
Although the method of the FBI’s entry into the San Bernardino shooter’s iPhone has been the source of many rumors, a new report from CBS News states that at this point in the process, “nothing of real significance” has been discovered within the device.
In certain cases the
??operation doesn't help with lengthly variable names, i.e.,
really.long.lvalue[expression] = really.long.lvalue[expression] ?? "". In addition to this other languages such as Ruby contain a pipe operator
really.long.lvalue[expression] ||= ""which works the same way and which is very popular. This lowers the barrier of entry for programmers from that language.
There are property implementation patterns that come up repeatedly. Rather than hardcode a fixed set of patterns into the compiler, we should provide a general “property behavior” mechanism to allow these patterns to be defined as libraries.
inoutkeyword indicates copy-in/copy-out argument behavior. In its current implementation the keyword prepends argument names. We propose to move the
inoutkeyword to the right side of the colon to decorate the type instead of the parameter label.
All of these are currently under review. Property behaviors look very useful.
Update (2016-02-17): SE-0035: Limiting
inout capture to
I propose we make it so that implicitly capturing an
inoutparameter into a escapable closure is an error. We added the explicit
@noescapeannotation in Swift 1.2, and have since adopted it throughout the standard library where appropriate, so the compromise has outlived its usefulness and become a source of confusion.
Previously: Seven Swift Snares.
Update (2016-02-23): Erica Sadun:
The Swift team has rejected three Swift proposals.
Beginning February 14th, many of our users who purchased from the Mac App Store have experienced an issue where the application crashes while opening. What we know, so far, is this is another certificate issue on Apple’s end, preventing applications from properly validating a Mac App Store receipt.
The official word from Apple is that, in general, restarting the Mac in question should resolve the issue. In addition, for OS X El Capitan users, Apple says updating to OS X 10.11.2 or later is required, and OS X Snow Leopard users should be sure the Mac App Store Update for OS X Snow Leopard is installed. While what we have here is technically similar to what happened last November, it’s not quite the same and, being on Apple’s end, not something we could’ve prepared for. We’re grateful for your patience and understanding!
We’re not seeing the issue in-house, but we’ve learned a restart does not resolve the issue – reinstalling the application itself does.
On 2 different machines, I had to delete the apps entirely and re-download them from MAS in order to get them to work. Quality.
Some of my Mac apps won’t open today. I know why, and I know a re-install fixes it…but…sigh. Mac App Store: It Just Works*
Yet another Mac App Store delight: today, several apps stopped opening (some say "verifying", some do nothing). Fixed by redownloading.
This CF is still biting me, months later
Mac admins who have previously downloaded installers from the Mac App Store may be seeing some of those installers displaying warning messages and/or failing to install as of this morning.
In the case of applications where the needed version is no longer available from the MAS, or the application itself is no longer available, there are two ways to handle this issue[…]
Unlike in November, I have not seen these problems on my Macs.
Update (2016-02-16): Gregg Keizer:
Apple’s support document […] added a caveat about OS X apps. “Users running OS X El Capitan (v10.11 or v10.11.1) may receive a notification that your Mac app is damaged if it utilizes receipt validation to request a new receipt from Apple,” the document said. “They can resolve this issue by restarting their Mac or updating to OS X El Capitan (v10.11.2) or later.”
Computerworld staffers running the latest El Capitan beta—OS X 10.11.4—encountered dead apps early Tuesday, including Byword, a text editor; the Fantastical 2 calendar; and Clear Day, a weather app. Some apps threw out a request for the Apple ID password used to access the Mac App Store—in some cases only a fleeting dialog box—but other apps just would not launch.
Restarting the Mac did not help.
We’re paying 30% for the privilege of explaining to Apple’s App Store customers why their purchased apps don’t work.
If you have a product in the Mac App Store, be advised that the MAS had a certificate expiration over the weekend. Brace for impact.
Yep. That was my guess—several MAS apps just started silently failing to launch. Reinstall fixes it, but... grr.
ah is that why none of my apps work :(
Yup, tried to do an El Cap re-install last night, “damaged Install” & can’t re-install
I would like to have thought they’d have this worked out after the last debacle but I would have been a fool to have done so.
Update (2016-02-17): The certificate problems seem to also be affecting FoldingText.
As a developer this is absolutely unacceptable and as a user it’s even worse (silent launch failure)!
Developers were notified in advance and support was set up to help (always can do better)
This seems to miss the points that users were not notified, that we’ve heard reports of support not being familiar with the issue, and that Apple’s recommended remedy doesn’t always work.
This tech note does not reflect my experience. I am running 10.11.3 and experienced the issue after cold boot on Monday.
As far as I know customers have never received anything from Apple explaining these failures or how to resolve them.
This is hard to do 140ch at a time. :-) But alas “we warned you” doesn’t take the edge off the customer’s pain…
…and time & time again, customers come to us angry about something we couldn’t possibly have dealt with in advance.
FWIW I believe Apple has prepared admirably for this but the specific issue Wade called out seems out of developer hands.
Delete and reinstall is not a solution. If purchased directly this wouldn’t have been a problem.
The problem was clearly announced, in the bottom of a drawer in a disused lavatory with a sign saying Beware of the Leopard.
It was working for me for several days after February 14, but starting this evening ReadKit will not launch for me. It reports (silently, in Console): “Failed to check receipt signature: No valid signer”. Neither of Apple’s two pieces of advice—that the OS will tell me the app is damaged and that I should restart—worked, but deleting and reinstalling did.
Update (2016-02-18): Adam Knight:
YAY! Another day that none of my Mac App Store programs will open. Thanks, Apple.
My understanding is that the developer’s only responsibility was to make sure that their receipt validation code works with the new certificate. In cases where users are having problems, the apps don’t seem to be getting to that point. Receipt validation is (correctly) failing because of receipts signed with the expired certificate. The store is then supposed to download a new receipt signed with the new certificate. This is not happening. [Update (2016-02-20): See these comments. I now think that the app’s receipt validation is incorrectly failing and that the system is (incorrectly) not downloading a new receipt.]
Update (2016-02-19): David Foltz:
@gte I know it’s not your fault. But Napkin failed to launch today. Had to reinstall. Is this @mjtsai’s fault? ;)
Update (2016-02-20): Apple has significantly added to its page about the certificate expiration:
In some scenarios, an app purchased from the Mac App Store that utilizes receipt validation may fail to launch (exiting with a 173 error code) since it considers a local receipt that includes the expired WWDR Intermediate certificate invalid. OS X regards the receipt as valid when the updated WWDR Intermediate is present on your system and therefore does not request an updated receipt for the application.
To resolve this issue, delete the renewed, non-expired WWDR Intermediate certificate from your System and/or Login keychain within the Keychain Access application. After re-launching the application, you will be prompted for your Mac App Store login credentials in order to obtain a new receipt for the application. After you have launched your application and obtained a valid receipt, you can re-install the renewed certificate to continue your development. This issue will be fixed in a forthcoming update to OS X El Capitan.
my list of Mac App Store Apps had to delete+reinstall due to Valentine’s Day Cert Massacre: BusyCal, Divvy, Fruit Juice, FoldingText, Shush
personal toll would have been higher but every chance I get I move my apps from Mac App Store to Direct. Don’t care if need to re-purchase
But for years, some Twitter users in OS X have had a problem with t.co in Safari. Instead of redirecting, the link results in an endlessly loading page that times out. Reloading the page results in a non-existent domain. Reload again, and the destination URL finally loads.
An Apple engineer who works on the WebKit team—the technology underneath Safari—recently tweeted in response to well-known Mac developer Rich Siegel and developer and podcaster John Siracusa that the problem has been identified, and a fix is underway. So relief is coming.
You can work around it by flushing the DNS cache or by telling Tweetbot to open the URLs directly.
And if it wasn’t for AppleWorks smoothing the way between Mac OS 9 and Mac OS X—as a high-profile example of an app that could run on both thanks to Apple’s Carbon libraries—then I suspect that a good many people like me would have clung onto the classic Mac OS for many more months and years. As it was, because Apple released a free update to AppleWorks (originally for Mac OS 8.1) which meant that the same app could run in both 9 and X, on those occasions where you booted into OS X to marvel at all the shiny, lickable buttons, you could actually also choose to get some work done. Launch AppleWorks under OS X and not only could you open the same documents as you created under Mac OS 9, but because you were literally using the same app, both the formatting of your documents and the interface of the application remained unchanged. In other words, you had one fewer excuses to dismiss OS X as a toy and reboot back into the familiarity and power of OS 9.
My beloved Douglas Adams once wrote a set of three rules describing our reaction to technologies, and though not intended as such, they act as a perfect summary of why some bits of tech tickle our sense of nostalgia and some don’t. “Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. Anything that’s invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. Anything invented after you’re thirty-five is against the natural order of things.”
See also: my AppleWorks 6 review.
Last night, Federico Viticci tweeted that he lost a draft blog post he was working on because of an iCloud problem:
“Just lost 1.5k words I had prepared for tomorrow because I wanted to try iCloud sync instead of Dropbox this week.”
I hear that people love iCloud Photo Library and Notes, and that the quality of these apps and companion services has significantly improved. That’s great. (I also think that CloudKit is clearly the best thing Apple has built for syncing yet.)
But to me, it doesn’t matter if it’s reliable or fast, or even if it “always” works. It only matters if I trust it when something goes wrong. Conceptually I’m not sure iCloud will ever get there for me.
Update (2016-02-12): Paul Jones:
I migrated to a Dropbox and Adobe Lightroom based workflow because of performance, reliability, power, and predictability. Perhaps Photos is simpler and more convenient for most consumers, but it just is too risky and too opaque for me.
A major reason for the initial creation of Piezo was our desire to allow recording from other applications on the Mac within the limits of what Apple’s Mac App Store rules allowed. We were pleased to provide audio capture to customers of the Mac App Store, and for a time, things worked just fine. However, Apple eventually began requiring that all applications distributed through the Mac App Store be sandboxed. This was a problem. Piezo’s need to capture audio from other applications precludes the possibility of it being sandboxed. This new requirement effectively stopped our ability to upgrade Piezo in any meaningful way.
We’d like to provide customers with the option of buying Piezo through the Mac App Store, but it’s more important to us that we provide a quality product with full functionality. In the case of Piezo, that now means exclusively distributing the application via our site. Users have always had the option of downloading and buying Piezo direct, so this didn’t involve much in the way of additional work. The biggest issue was simply choosing to remove Piezo from the Mac App Store. Ultimately, we feel the decision was made for us by both technical and bureaucratic factors outside of our control.
Ideally, the interface to
NSURLSessionwould be protocol based. We could create a mock object that conformed to this protocol and use the objects interchangeably under test.
Unfortunately, Apple hasn’t fully embraced protocol-oriented programming in its framework code. No worries; we’ll create our own protocol, and have
NSURLSessionconform to it via an extension.
We don’t actually have to implement anything in this extension because we kept the method signature the same as Apple’s framework. Meaning,
NSURLSessionalready implements our protocols required methods.
The error is occurring because
NSURLSessiondoesn’t have a
dataTaskWithURL()method that returns our custom protocol. To fix this, we just need to extend the class a little differently.
Here we implement the method in the protocol manually. But instead of doing any actual work, we call back to the original implementation and cast the return value. The cast doesn’t need to be implicit because our protocol already conforms to Apple’s data task.
This is a subtle bit of code where the protocol and class have methods with the same name and arguments but different return types. So it’s an overload rather than an override.
To keep our tests running fast let’s completely flatten the code path. One thread, no asynchronous behavior, no network activity.
Now we can set what data and/or error is returned from the
dataTaskWithURL()method. But wait, that method returns a data task, right? Correct, but look at the last parameter.
The completion handler would normally be called by the API when a real network request returns. We need to replicate this while we build our own mock. To do so, simply call the handler with our “next” variables before returning.
Previously: Swift Protocols.
Update (2016-11-12): Part 3.
We’ve encountered an issue on the Mac where Adobe Creative Cloud appears to be removing the contents of the first hidden folder at the root of the drive, in alphabetic order. By happenstance, the first hidden folder on most Backblaze customer’s internal drive is the .bzvol folder.
As a workaround, they suggest creating a new top-level folder whose contents you don’t care about: /.adobedontdeletemybzvol.
Update (2016-02-12): Brian Webster:
Yup, this happened to me the other day.
Thank you Adobe for making all your installers require admin privileges.
If Apple strived to make the Sandbox fulfill more needs, I think many more apps would be sandboxed.
OS X would be a more secure platform if developers could sandbox, declaring ALL their behaviors, whether they fit long-term goals or not.
In this scenario, an app like Adobe’s might have “I need to delete /.adobe”, and the system would prevent it deleting /.bzvol.
Because Apple’s sandboxing limitations are so rigid, some developers who would otherwise “do the right thing” won’t even bother trying.
Adobe Creative Cloud is a great example of why Apple’s sandbox is nigh-useless. Because Adobe only sells it direct, so no sandbox.
Small developers are stuck in a barely functioning, almost impossible to use sandbox while one of the largest is deleting our files.
Update (2016-02-16): Adobe:
Earlier today we were notified of an issue with an update to the Creative Cloud Desktop application on Mac that we rolled out earlier in the week. In a small number of cases, the updater may incorrectly remove some files from the system root directory with user writeable permissions.
We have removed the update from distribution, and are in the process of deploying a new update which addresses the issue. When prompted for the update, Creative Cloud members should install it as normal.
Adobe fixed the issue on Sunday with version (188.8.131.52). All users of Adobe Creative Cloud can now update their software.
Creative Cloud pushes the user to enable auto-updating, and many people opt-in for the sake of convenience. It’s a fine idea, and ordinarily it should increase security and stability too, but more importantly it’s a gesture of trust. When that trust is violated, the damage done to the vendor’s image and their relationship with the customer is severe. Adobe has a long history of Byzantine installations and concomitant problems, and this one takes the cake – especially from a large company which readily has the resources for extensive QA, and a great deal to lose.
For our own apps we can test and tune the caches to avoid this, but the Objective-C runtime doesn’t have this option. Because the method cache is so critical to performance, and because each entry is relatively small, the runtime doesn’t impose any size limit on the caches, and expands them as necessary to cache all messages that have been sent.
Note that the caches do sometimes get flushed; any time something happens that might cause the cached data to become stale, such as loading new code into the process or modifying a class’s method lists, the appropriate caches are destroyed and allowed to refill.
Note that there is no need to block execution of
objc_msgSendfor this to work properly. Once the cache free code is sure that nothing is in
objc_msgSendat any particular moment after it has replaced the cache pointer, it can go ahead and free the old one. Another thread might call out to
objc_msgSendwhile the old cache pointer is being deallocated, but this new call can’t possibly see the old pointer anymore, so it’s safe.
The purpose of the hypothetical global counter is to track when any thread is within a particular region of code. Threads already have something that tracks what code they’re currently running: the program counter. This is the CPU register which tracks the memory address of the current instruction. Instead of a global counter, we could check each thread’s program counter to see if it’s within
objc_msgSend. If all threads are outside, then it’s safe to free the old caches. […] Then
objc_msgSenddoesn’t have to do anything special at all. It can access the caches directly without worrying about flagging that access.
I’ve been using Xcode’s continuous integration feature for a few months now. Overall, I’m glad that I took the time to set it up. However, it’s been much more difficult to use than I expected, so I want to document some of the issues that I encountered, as well as the benefits:
It’s nicer than I expected to have tests run automatically, on a different machine. My tests don’t take that long to run, but it’s enough of an interruption that I would not naturally run them all for every commit. Tests can also run asynchronously. One day I wrote some code in a waiting room, while work was being done on my car. Sooner than expected, it was time to pack up and go. I pushed my changes to the server, and by the time I got back to the office all the tests had run.
While working on one app, I am not good at remembering to run tests for other apps. In part, this is because Xcode doesn’t like to have two projects open that each reference the same subproject. And so sometimes I would be working on a shared framework, cause a minor breakage in another app, and not realize it until days or weeks later when I was working on that app. Bots catch this type of bug (or failure to compile) right away.
My apps still have 32-bit versions, and bots make it much easier to test both architectures. When manually running tests within Xcode, you have to pick 32-bit or 64-bit. I had been using a shell script to test all the architectures, but that had the disadvantage of not showing the results within Xcode. And if I made the script do a clean build, which was frequently necessary, Xcode would temporarily lose its index information, which affected the syntax coloring and navigation. This is not a problem with bots, which use a separate working directory.
Likewise, it was an extra step to run the static analyzer, so I tended to only do this before a release. With bots it’s easy to do this every time.
The same is true for code coverage.
Getting my code to run in the bots environment found some latent problems in my projects: some files that weren’t using proper relative references, some tests that depended on file metadata that wasn’t stored in Git, some tests that were too closely tied to the environment of my main development Mac (documents, apps, preferences, user spelling dictionary), some target dependencies that were missing. Some shell scripts didn’t have proper quoting, which I never detected because my build folder had no spaces in its path—but the bot’s did.
I also had to copy various items into the keychain on the Xcode Server Mac. Many keychains seem to work with Xcode, but for bots your certificates (e.g. for Developer ID or the Mac App Store) must be in System keychain.
On the other hand, some tests just don’t plain work in bots. Some keychain and address book tests would fail or hang, eventually causing the integration to abort with no results or errors. I now exclude these tests when the code is running as user _xcsbuildd.
Sometimes my test code would crash, seemingly due to an OS bug, but only when running in the bot. If a test crashes there is no way to view the crash log in Xcode. You have to download an archive of all the logs and then extract it.
Oddly, I also found two cases where the static analyzer found legitimate problems (in generated yacc code) when running on the bot that it did not find when running from Xcode. I have not found an explanation for that. The versions of Xcode and Mac OS X were identical.
I was never able to get bots to send me status e-mails from Mac OS X Server. I tried both the built-in mail server as well as giving it my credentials for various SMTP servers. I read lots of blog and forum posts and tried all kinds of remedies but was never able to figure out. It never even gave me any useful error messages. I ended up writing a trigger script for the bot to run that POSTs the environment to my Web server. Then I have another script there that formats the information into an e-mail. This works, but the e-mails don’t look as nice or have as much information as the built-in Apple ones are supposed to. On the other hand, if there’s a failure I’ll probably have to go read the details in Xcode, anyway. So I just have simple e-mails that report the numbers of tests, warnings, errors, and failures, and I have Mail rules to color the messages green or red.
I have successfully used Git with SSH keys, but this has never worked for me with Xcode bots. So instead I am using password authentication.
I have 1–2 bots for each product, and each bot needs a full checkout of the Git repository. My repository is rather large because it includes all my products, my Web site, and each shipped .dmg file going back to 2002. Multiplying that out, it took a lot of disk space and a really long time for the initial checkout. I was originally going to have bots for each project (framework, app, or other target), but I settled on per-product to reduce the number of checkouts.
One of the reasons I have multiple bots per product is that each bot has to pick either one architecture or “All Architectures”. Swift code doesn’t compile for 32-bit, so it has to be in a different bot than my universal code.
The bots interface within Xcode seems pretty buggy. Viewing the commits tab usually crashes. Sometimes the latest integration shows in the Web interface but not in Xcode. Sometimes I have to click Load More in Xcode to see the latest integration, even though that is usually for loading older integrations. Sometimes no matter what I do it won’t show up in Xcode.
As with Xcode itself, bots sometimes get wedged with strange errors, and you have to clean the build folder before anything will work. There’s an option to have Xcode do this periodically, but I haven’t found that to be useful. Clean too often, and the builds are really slow. Clean less often, and you end up with spurious errors. I end up frequently doing manual cleans, by holding down the Option key so that the Integrate button changes to Clean Integrate.
Note that clean integrations do not do a fresh Git checkout from the server. However, every once in a while, all the bots seem to decide that it’s time to do a fresh checkout, and that’s really slow.
Sometimes a clean integration won’t fix a weird error, and the only remedy seems to be to restart the server Mac itself.
Here are some examples of weird errors that were fixed by cleaning or restarting:
Assertion: Directory not found for option '-F/Library/Developer/XcodeServer/Integrations/Caches/b24b1b6ee61325ff5108b238601fffb2/Source/Programming/DropDMG/DerivedData/Build/Products/Release' File: (null):(null)
(Early unexpected exit, operation never finished bootstrapping - no restart will be attempted)
Assertion: warning: /Library/Developer/XcodeServer/Integrations/Caches/525e758732df9b9483e63d7361008702/DerivedData/ModuleCache/1RAFTB1Y99NEJ/MJTFoundation-1W2RPA2S3CGSV.pcm: No such file or directory
Assertion: warning: /Library/Developer/XcodeServer/Integrations/Caches/525e758732df9b9483e63d7361008702/DerivedData/ModuleCache/1RAFTB1Y99NEJ/MJTFoundation-1W2RPA2S3CGSV.pcm: No object file for requested architecture
Assertion: warning: /Library/Developer/XcodeServer/Integrations/Caches/525e758732df9b9483e63d7361008702/DerivedData/ModuleCache/1RAFTB1Y99NEJ/Foundation-3M4TH6X8B5VB4.pcm: No object file for requested architecture
Assertion: warning: Could not resolve external type c:objc(cs)XCTestCase
Assertion: warning: Could not resolve external type c:objc(cs)MJTTempFolderManager
Assertion: warning: Could not resolve external type c:objc(cs)NSURL
Assertion: warning: Could not resolve external type c:objc(cs)NSString
Assertion: Running task was terminated because it produced no activity for too long.
warning: no debug symbols in executable (-arch x86_64)
Sometimes it seems to get stuck doing a Git checkout. There doesn’t seem be a way to make it cancel and retry, so I have to restart the server Mac to unwedge it.
Sometimes the server seems to stop checking for new commits. I then have to run the integrations manually or restart the server Mac.
Sometimes the server Mac spontaneously suspends (I see the Apple logo and progress bar.) and restarts itself while doing an integration.
In one case, no amount of cleaning or restarting would get the bot to use the proper configuration (either from the scheme or overriding it in the bot), and I had to delete and recreate the bot itself.
Sometimes bots try to run while the Mac is in Power Nap, and that’s usually a disaster: weird failures or errors that have nothing to do with any code that I recently changed.
Whenever you update Xcode, you have to reselect it in the Server app. With Xcode 7.2.1, this is impossible. Bots don’t seem to work with this version of Xcode at all. I went back to 7.2, but I don’t like the idea of bots using a different version of the compiler than what I’m using for development and production.
I chose Xcode’s continuous integration instead of something like Jenkins because, coming from the makers of Xcode, I thought it would be easier to set up and less prone to breakage. This may well be true, but it’s not been anywhere near as simple as I’d hoped.
However, I’m now seeing a bug where Xcode reports the bot integration as still running long after it’s finished (and the trigger has run).
And, crucially, Google will favor AMP sites over others with the same search score in the results it shows consumers, said Richard Gingras, senior director, news and social products at Google.
Via John Gruber:
Previously: Google’s Accelerated Mobile Pages.
Update (2016-02-16): John Gruber:
Important correction from Ad Age, regarding the claim earlier this week that Google would favor AMP page in search results.
Generally speaking, if you’re an active participant of the the swift-evolution list, you’re already quite bought in on Swift. This is generally a good thing, since being bought in on Swift means you care a lot about its future, and you have a lot of context from working with current Swift, too.
But by only getting suggestions and feedback about Swift’s evolution from those bought in on Swift, the Swift team is largely neglecting those who are not already on board with Swift. This includes those holding out with Objective C on Apple’s platforms, and those using different languages on other platforms too. These groups have largely no influence on Swift’s future.
And thus, Swift becomes less likeable to these Objective C developers.
We can see that it’s exactly as we expected: when passing the
structis laid out contiguously in memory and then a pointer to it is passed in.
structstorage in Swift is ultimately pretty straightforward, and much of what we’ve seen carries over from C’s much simpler
structinstance is largely treated as a loose collection of independent values, which can be manipulated collectively when required. Local
structvariables might be stored on the stack or the individual pieces might be stored in registers, depending on the size of the
struct, the register usage of the rest of the code, and the whims of the compiler. Small
structs are passed and returned in registers, while larger
structs are passed and returned by reference.
structs get copied whenever they’re passed and returned. Although you can use
structs to implement copy-on-write data types, the base language construct is copied eagerly and more or less blindly.
I remember being very surprised when I first encountered modern vector editing tools. Many of the interactions felt broken. Why couldn’t you just manipulate things directly? Why did connecting and disconnecting stuff only sometimes work? Is this the best we can do?
The pen tool as we know it today was originally introduced in 1987 and has remained largely unchanged since then. We decided to try something new when we set out to build the vector editing toolset for Figma. Instead of using paths like other tools, Figma is built on something we’re calling vector networks which are backwards-compatible with paths but which offer much more flexibility and control[…]
A vector network improves on the path model by allowing lines and curves between any two points instead of requiring that they all join up to form a single chain. This helps provide the best of both worlds; it combines the ease with which points can be connected on paper and the ease with which geometry can be manipulated once it’s drawn. Splitting and recombining geometry is much more natural with vector networks. Delete anything, anywhere. Connect anything to anything else.
In addition to dragging the control handles, Figma’s bend tool (the command key on OS X) lets you drag the curve around directly.
Via John Gruber:
I have never been able to make heads or tails out of Illustrator’s vector design tools. (R.I.P. Freehand.) The Figma designers have come up with something truly novel — looking forward to trying this.
But, back before they invented railroads, there were no time zones. And OS X knows this! So, before time zones were introduced, the local time doesn’t get shifted to the time zone. And, if your local time is one a different calendar date than Greenwich, you’re off by one day!
No one is going to anticipate bugs like this, bugs that depend on the invention of the railroad. TDD is great, but Coplien is right; you’re never going to get everything through testing.
Apple’s documentation policy attempts to tell you what you need to know, and no more. This gives Apple flexibility to improve OS X in small ways without breaking its implicit contract with developers, and keeps the documentation small. Here, though, the time zone behavior is completely undocumented.
Apple’s Time Machine backup system was born in a time (2006) when Apple realized that customers weren’t routinely backing up their Macs. So a simple, stopgap system, with some novel features, was devised for the novice user. Unfortunately, over the years, the app hasn’t progressed and kept pace with modern user needs. Today, most every tech writer says: Use it, but don’t trust it completely. This is an unfortunate situation.
For example, Time Machine doesn’t, in normal operation, create a bootable backup of the internal drive. It can only restore a damaged (or new) internal drive from the Time Machine archive.
Next, there is no easily digestible, user accessible log file available for inspection within the Time Machine System Preference.
Finally, there is very little in the way of diagnostics or feedback to the user about the integrity of each backup. In other words, the user has no usable tools within Time Machine. that can be used to verify the integrity of the current backup other than a casual visual inspection. If a Time Machine backup gets hung up or mangled, most users are left in the dark and find themselves forced to start all over, regretting that a possible valuable archive needs to be overwritten.
Now to answer the ultimate question, how do I get best performance with Core Data? Is the question that I can un-answer in the abstract. I think that your best bet is to look at the architecture, to understand this architecture, to really see how do these different layers work. How are their performance characteristics of these layers and then reason about your app’s behavior with this background knowledge. When you do that you can make the right choice for your specific project.
The advantages of the [nested contexts] set up are that if you save stuff from the main context, for example, the scenario I mentioned before, you copy in tons of data into your app, just copy paste and then you save. Now the save doesn’t block the main thread any more. Because the save of your UI context, only pushes all this stuff down into this private context that’s below. The private context can save this later. It’s one of the major advantages, and one of the major reasons nested contexts were introduced with iOS 5, where there’s iCloud syncing stuff.
Another disadvantage is that saving a child context pushes all changes down into the parent context. So before I said when you merge change, merge save notifications, Core Data can discard stuff because it knows it is not of interest to the other context. Now, with nested context, Core Data has to channel all this data down to the store, so it has to push all of this in. So if you insert 10,000 objects in the child context, Core Data has to instantiate 10,000 objects in the parent context, even if you don’t care about them there.
Another disadvantage is that you have no merge policies. When you work with nested context, you save the child context and all the changes are pushed down into the parent context with brute force. There is no consideration about conflict resolution, this is just a brute force push down into the previous context. It just overrides. Another pretty esoteric issue is that once you work with nested contexts you have to be aware there are weird things going on with temporary and permanent object IDs, and you can run into weird situations where you can break stuff like the uniquing guarantees that Core Data usually has.
iOS at least helped users, in providing a Reduce Motion option in the Accessibility section within Settings. Within six months, most of the worst animations were possible to replace with non-aggressive crossfades, much to the relief of vestibular disorder sufferers worldwide. But we’ve seen no such progress on OS X, and tvOS recently appeared with a ‘Reduce Motion’ setting so ineffective that it may as well have played a little sniggering noise when activated.
El Capitan kills the one remaining workaround I had that enabled me to safely use full-screen apps. System Integrity Protection, while essential to the security of the Mac, more or less kills off applications that inject code into OS X. TotalSpaces2 is one of them. The app was designed to manage desktops in a manner akin to those in OS X 10.6, but, importantly, included settings to customise transitions.
Via Adam C. Engst:
Although it’s impossible to know what percent of the population suffers from vestibular disorders, estimates range from 5 to 35 percent, meaning that there could be many millions of people out there who endure some level of discomfort due to unnecessary animations and effects. We’d like to see Apple extend its accessibility work in iOS to its other operating systems (including watchOS, which Grannell doesn’t discuss).
I don’t have a vestibular disorder, but I use Reduce Motion and Reduce Transparency wherever possible.
But even with a full rewrite, KVO’s underlying pattern makes things harder to maintain and debug. Ad-hoc property-observation is just a bad idea.
After the pitch, GE decided to go with another agency, and all those weeks of late nights turned out to be for naught. Both Uncle Sam and Lemmings ended up in the dead file.
Some time later, we received a communique from the LA office. Given all the attention that had been focused on Apple and Chiat/Day for the extraordinary 1984 commercial, the quest was on for an equally powerful follow-up in the next Super Bowl. The LA office was struggling to come up with worthy ideas and they invited the NY office to help. The focus for the new ad would be Apple’s push into business with a combination of hardware and software called the Macintosh Office.
If you know the story of 1984, you know that the idea struck when the LA creative people were searching for inspiration, pouring through old presentations to see if there might be a spark of an idea. They came across a print ad with the headline, “Why 1984 won’t be like 1984.” That got their attention. The rest is history.
Well, a similar thing happened in the NY office in the search for a new Apple Super Bowl idea. Someone had the great idea to look at the work that had been done for GE. And there it was — Lemmings, in all of its glory.
If you’re in Pages, TextEdit, Nisus Writer Pro, BBEdit, or the like, you can Control-click the word, which will no longer have that red underline, and choose Unlearn Spelling to reverse your action. But if you’re in Safari, Google Chrome, or any other app that supports spell checking without implementing it fully, no Unlearn Spelling command is available.
The clumsy solution is to copy the offending word, paste it into TextEdit or a similar app, Control-click it there, and choose Unlearn Spelling from the pop-up menu. Effective, but awkward, particularly if you’ve ended up with a number of misspelled words in your dictionary over the years.
Here’s an alternative solution — you can edit your list of learned words directly, since it’s just a text file.
Google (in 2015):
As part of our constant efforts to improve account security, we analyzed hundreds of millions of secret questions and answers that had been used for millions of account recovery claims at Google. We then worked to measure the likelihood that hackers could guess the answers.
Our findings, summarized in a paper that we recently presented at WWW 2015, led us to conclude that secret questions are neither secure nor reliable enough to be used as a standalone account recovery mechanism. That’s because they suffer from a fundamental flaw: their answers are either somewhat secure or easy to remember—but rarely both.
For years, we’ve only used security questions for account recovery as a last resort when SMS text or back-up email addresses don’t work and we will never use these as stand-alone proof of account ownership.
In parallel, site owners should use other methods of authentication, such as backup codes sent via SMS text or secondary email addresses, to authenticate their users and help them regain access to their accounts. These are both safer, and offer a better user experience.
Via John Gordon:
FWIW my security question ‘Fake Answers’ are basically unique random passwords - secure but a royal pain to manage.
It seems that the age of platforms keeping to themselves and shutting out rivals is on the verge of ending. Now platform makers are actually playing to the strengths of their rivals as well. Apple has surprisingly made available not one but two Android apps, though one of them has been critically panned by Android users. Just recently, Apple updated its Apple Music app to add a feature that is technically impossible on the iPhone: saving music to a micro SD card for offline listening.
That move hinted that Apple was serious about its Android app, and apparently that was indeed more than the case. Under Cook, Apple has been trying to portray an image of a services company more than just a hardware and OS maker. Those services include iCloud apps and storage, Apple Pay, and iMessage, just to name a few.
In addition to providing a web interface for users to access the same data as your app, you can now easily read and write to the CloudKit public database from a server-side process or script with a server-to-server key.
Update (2016-02-09): Nathan Ingraham:
Cook may feel he needs to fight back and bring more Apple apps to Android -- but he first needs to make sure the company’s software runs better on its own hardware than it currently does.
This is fascinating insight into the, I suppose unsurprising, mindset of many venture capital investors. They’re not looking for a profitable business; instead, they’re looking for growth that provides the opportunity for a 100x exit. And their expectation is that you, the founder, will work to achieve that at any cost. And since their investment also brings the expectation of participation and inclusion in the running of the business, any company owner considering taking on investment would be well advised to make sure at the outset that everyone’s on the same page in terms of objectives.
Finally, it’s also worth noting that not all investors in Gimlet shared the mindset of Chris Sacca. We also discover that Marco Arment—of Tumblr, Instapaper and Overcast fame—is also an investor in Gimlet at a participation of $150,000. In interviews with Marco, he encourages Alex to forget about the ambitions of the other investors, focus on what he’s good at, and above all, listen more to his wife!
We’ve been hearing about a lot of drama going on at $2 billion startup GitHub, the hugely important and popular site used by millions of computer programmers where 10 or more executives have departed in recent months.
Its once famous remote-employee culture has been rolled back. Senior managers are no longer allowed to live afar and must report to the office. This was one reason why some senior execs departed or were asked to leave, one person close to the company told us.
Underlying the drama is the fact that GitHub is trying to grow the company’s revenues by landing more big enterprise contracts. And it’s doing a good job of that, several sources — even the disgruntled ones — told us.
That means there’s an effort to hire more enterprise salespeople, with all the suit-and-tie salesforce culture that typically includes. (GitHub employs over 80 sales folks according to LinkedIn.)
Meanwhile, the company’s millions of developer users, many of whom use the site for free or for a small monthly fee, also want GitHub to pay more attention to them. A bunch of active and influential users sent a letter in January called “Dear GitHub” in which they asked for a bunch of product features, too. At least one person told us that this letter alarmed some of the leadership team.
Resultis not built in the Swift standard library, and a lot of functions use
throwto report synchronous errors anyway. Like in practice, to build a
NSDictionarywe might have a
init(dict: NSDictionary) throwsconstructor instead of a
NSDictionary -> Result<User>function.
So how to mix both those worlds? Easy: let’s extend
Resultjust for that!
In case of multiple integers in the same expression, Swift can only infer the type of free integer literals when they are used with some typed variable of one single type, as before, no implicit conversion toward the bigger integer type is performed.
The only drawback of this safety-first/no-assumptions approach, is that when you need to perform a lot of type conversions, you code starts to become bloated with all those truncating conversions.
But luckily, in Swift we can extend base types with new methods and we can use this to add some utility methods that truncate to a specific size to all the integer types[…]
All the alternative approaches to manipulate bit sets presented in this post are part of Bitter, a library that try to offer a more “swifty” interface for bit sets manipulation.
Some time later, I came across Iavor’s “jokes” page, including a funny bit called “The Evolution of a Programmer“ in which the traditional imperative “Hello, world” program is developed through several variations, from simple beginnings to a ridiculously complex extreme. A moment’s thought turned up the factorial function as the best functional counterpart of “Hello, world”. Suddenly the Muse struck and I knew I must write out these examples, culminating (well, almost) in the heavily generalized categorical version of factorial provided by Uustalu, Vene and Pardo.
On a more serious note, I think that the basic idea of the joke (successive variations on a theme, building in complexity) can serve a good pedagogical purpose as well as a humorous one.
Update (2016-02-09): Comments from Hacker News.
Thousands of iPhone 6 users claim they have been left holding almost worthless phones because Apple’s latest operating system permanently disables the handset if it detects that a repair has been carried out by a non-Apple technician.
Relatively few people outside the tech world are aware of the so-called “error 53” problem, but if it happens to you you’ll know about it. And according to one specialist journalist, it “will kill your iPhone”.
In summary, Apple iOS uses a validation system to ensure Touch ID sensor is not maliciously replaced or modified. The Touch ID sensor has access to the iPhone Security Enclave, where fingerprint data is kept. A malicious sensor could, hypothetically, steal fingerprints from an iPhone user unknowingly. This could be used to unlock the phone and make purchases through Apple Pay without the owner’s permission. To prevent this, Apple uses a validation system whenever the Touch ID sensor is repaired. When iPhone is serviced by an authorised Apple service provider or Apple retail store for changes that affect the touch ID sensor, the validation paring is updated. Third-party repairs to the sensor will not update the pairing, and will fail validation when using Touch ID. This validation error is shown to users as the mysterious “Error 53”.
If the validation fails, the device will function mostly fine, although with Touch ID disabled. However, the device will be prevented from restoring or updating to a new version. Restoring from backup still works. I’m not too sure why restoring or updating is blocked, but my guess is that they want to prevent malicious software from being uploaded in this process.
No, the CPU reads encrypted data from the sensor and sends them to the SE for decryption and analysis. See the PDF linked here by somebody. What a malicious sensor could do is store user’s fingerprint for retrieval by unauthorized parties.
It seems very reasonable to me that iOS should check for a trusted Touch ID sensor. But, if the sensor can’t be trusted, clearly the whole phone should not be bricked — it should simply disable Touch ID and Apple Pay. And, obviously, it should inform the user why. Putting up an alert that just says “Error 53” is almost comically bad.
Update (2016-02-11): Gwynne Raskind:
You must predicate everything you do in the name of security on the presumption that users are hopelessly lacking in knowledge.
They WILL be socially engineered into giving up credentials.
They WILL be socially engineered into turning off security features that give them even a moment’s annoyance even just once.
A number of people have asked why Apple didn’t disable just Apple Pay and leave the rest of the phone functional. Technically speaking, I can’t do more than guess at the details, but it’s my presumption that this is the only way they could prevent jailbreaks and other “the user will do any stupid thing rather than actually listen to security warnings” (the effect of user arrogance on security is a whole separate issue from user ignorance that I’m not going to get into) from getting around the error, which would have rendered it useless.
Update (2016-02-16): Josh Centers:
We reached out to an Apple Authorized Service Provider who is familiar with the matter. While he confirmed that Apple’s requirement is a security feature, he also sees it as Apple pushing several agendas: selling AppleCare+, pushing customers into buying new phones after AppleCare+ expires, shutting out non-authorized repairers and suppliers, and shutting out fake devices built from knock-off parts. It turns out that all iPhone screen repairs have to go back to Apple for screen replacements; Apple has a machine that restores the pairing between the Touch ID sensor and the secure enclave.
Apple’s handling of the situation has prompted the Seattle law firm PVCA to file a class action suit against Apple; if you’ve experienced Error 53, consider getting in touch with them.
However, it’s not all bad news. In order to deal with unauthorized repairs, Apple has drastically reduced the price for out-of-warranty screen repairs. Without AppleCare+, the company now charges between $109 to $149 for a screen replacement, which isn’t much more than what you’d pay with AppleCare+. However, if you have AppleCare+, Apple will give you a loaner phone and likely move your repair up in its priority list.
That’s not a unique business model, of course. For decades, auto manufacturers and dealerships have done their best to undermine independent garages by limiting access to original parts and diagnostic tools. The results, in both industries, are predictable: Repair shops have to turn away willing customers, and consumers lose the benefits of free competition, notably lower prices and more convenience.
In 2000, under threat of so-called “right to repair” legislation, U.S. automakers, dealerships and service shops formed a union to share information on repairing today’s high-tech cars. Because membership was voluntary, however, there was little incentive to cough up any useful data, especially in a prompt manner.
The update is not for users who update their iPhones over the air (OTA) via iCloud. If you update your phone that way, you should never have encountered Error 53 in the first place. If, however, you update via iTunes or your phone is bricked, you should be able to plug it into iTunes to get the update today, restoring your phone’s functionality.
That Error 53 thing everybody said was Super Important Security Stuff™ was an inadvertently released factory test.
I’m not trying to accuse Apple of anything here; I’m personally satisfied with how they’ve handled the Error 53 situation. While I favor “right to repair”, and strongly dislike the trend towards hardware that the customer doesn’t effectively own, security of a device carrying important data in the context of the infamous gullibility and technical inexperience of the majority of users is a knotty problem at best and Apple is walking a fine line with relatively few missteps (though the “few” here is a long, long way from zero). What I do wonder about is what more there is behind some of the decisions that were made, and the timing of those decisions. If nothing else, it’s a matter of curiosity.
Update (2016-02-20): Alex Cranz:
AJ Forsythe is familiar with Error 53. He’s the CEO of iCracked and like many iPhone repair services, they’ve been aware of the problem for over a year now. […] Most third party repair agencies have learned to live with the quirk and have standardized their training of repair agents to accommodate this specific issue. (The companies that didn’t are the ones likely leading to the majority of brickings).
Update (2016-05-25): Husain Sumra:
Apple argued the lawsuit should be dismissed because the company issued a fix for the error and offered to reimburse customers who had paid to have their devices replaced or repaired. However, the plaintiffs are now arguing that Apple failed to properly alert users to the reimbursement program. They argue the “vague” announcement on Apple’s website and a support document published in April isn’t sufficient enough to inform affected customers.
The Apple Watch is a confused product, designed like a tiny iPhone, which is as misguided as it would’ve been to design the iPhone with the Mac’s UI and app structure. The result is promising, but clunky and slow. It could be so great at its three most useful functions — notifications, activity tracking, and timekeeping with robust complications — if only they were more reliable and better executed. Someday, I hope they are.
To be great, the Apple Watch needs to be rethought to do less, better. I see no signs that Apple is heading in this direction, but never say never.
Apple has aggressively pushed the Apple Watch as high fashion, but it’s simply not. It’s a utility watch, much like quartz watches, that has many useful functions and can be made to look very nice but won’t ever be a prestigious fashion item. There’s no shame in that. The sooner Apple realizes this and lets the Watch be what it really is, the better.
Some time last week my iPhone started prompting me frequently to re-enter my iCloud password. And then my Watch started doing the same, about once a minute — with a little tap on the wrist each time.
Obviously I did re-enter my password — and have done so a dozen or so times now — but it doesn’t seem to matter.
Lots of interesting tidbits, including the fact that Apple Watch sold better in its first holiday quarter than the original iPhone did in 2007.
Update (2016-02-10): Nick Heer:
I find these two articles, which were published within days of each other, completely compelling in their disagreement. Arment is a long-time tech guy who does not find Apple’s effort good enough — in many places, he sees it as unfinished. Forster, meanwhile, is someone who wrote a book on Cartier’s watches, and is used to wearing tiny lumps of metal on his wrist that are worth more than a car.
Every now and then — seemingly at random — I get a full screen advertisement imploring me to sign up for Apple Music. I’ve even disabled Apple Music in the Music preferences. For the love of all that is good, leave me alone. I know Apple knows I tried the Apple Music service and canceled it before the free trial was over due to bugs.
iCloud Music Library, which was a requirement of Apple Music, caused data loss where it would randomly delete my playlists that predated Apple Music. […] That was all supposed to be old news, but then I wanted to listen to a playlist yesterday. All of my playlists were gone, except for one playlist of Star Trek film scores, and the automated “Purchased” playlist. How could this happen? I haven’t had iCloud Music Library enabled, or Apple Music.
What was once a major strength of Apple — a simple-to-use music player and digital storefront — turned into the kind of garbage software that runs on cable company set-top-boxes. The experience has been turned into something more akin to a website for a print publication. You’re constantly jumping in and out of various things, which slide in from different directions, the stuff you want is buried several taps deep in hierarchical menus, and it’s centered around getting you to sign up for Apple Music.
If you try to share something purchased on iTunes, but not in Apple Music, it doesn’t generate an iTunes link, it generates nothing. It succeeds at generating nothing, which is the really wild part, since obviously, I wanted to send a completely empty tweet.
Rosensteel’s comparison to a publication’s website is absolutely apt, though, for at least one big reason: the gross interstitial ad that appears if you launch Music without having Apple Music enabled, and the tiny tap target on it to close the ad without purchasing a subscription.
Even after accounting for devices used in regions where Apple Music is not available, devices owned by subscribers, and devices — like Macs — where an interstitial full-screen ad doesn’t appear, that still leaves hundreds of millions of devices used by tens of millions of people who see that gross interstitial ad as frequently as every single day.
Previously: Apple Pushes iPhone 6s Pop-up Ads to App Store.
When I think about where I’m most productive with OS X, it’s always at my desk, where I have a huge monitor (on my iMac, at home) or even two Cinema Displays (at work). It’s so much more comfortable to be able to manipulate the operating system’s myriad windows when I have copious amounts of screen real estate, just as it’s so much more pleasant to have a full keyboard (with a number pad!) and the physical desk space for all of the many peripherals—printer, scanner, USB hub, etc.—that really complement the desktop OS experience.
To be clear, I don’t argue the fact that OS X is still the best platform for heavy duty work, and that it is likely to continue to be that for years if not decades. But it seems apparent to me that it’s at its most potent in its original form: on the desktop, where immensely powerful chips do best and battery life is not an issue. When I think about what I want to be using in the near term, I would much rather own a fast and fully stationary iMac and an iPad running a much more productivity-capable version of iOS, than just a MacBook.
In 2010 and 2011 we all got excited and thought the iPad would be an amazing and cool addition to our lives, but after a few years it turned out that we’re fine using our smartphones and our computers.
As a result, the iPad reached a huge percentage of its target audience in a very short period of time. And once that audience was exhausted, it rapidly shifted into an upgrade-and-replace product cycle. Imagine a world where the iPad didn’t sell 67 million units in the first couple of years, but found its audience more slowly. We might end up with an iPad market just as large as the one we have today, but with a sales chart that looks much healthier.
He particularly looks at four points that may have contributed to its fall in sales, but none of them answer the problem entirely. I think the iPad solved a problem that many people didn’t know they had, but that most people simply don’t need or want one.
I completely agree with Vinh about the usefulness of a desktop Mac, and yet I don’t have one. Instead, I use a MacBook Pro that nearly all of the time has a keyboard, mouse, external display, and lots of drives and peripherals attached.
The reason is that, although I’m rarely out of the office, when I am the iPad doesn’t let me get my work done. Having both a desktop Mac and a MacBook Pro would seem to make sense, since an iMac or Mac Pro would be much better when I’m at my desk. But I’ve tried that before, and it’s too much of a pain to administer two Macs and keep them in sync. Hence the compromise of a MacBook Pro that’s underpowered both at the office and on the go.
My ideal Mac would be less of a mobile device than a portable or luggable one. Even when traveling I’m more likely to use it on a desk or table than on my lap. And it will almost always be plugged in. So instead of thinness and battery life, give me a huge screen, a faster processor, and lots of internal storage. The 17-inch “aircraft carrier” PowerBook G4 was great but didn’t go far enough. I would love to have two spinning hard disks in addition to the SSD. Who wants to travel with bus-powered drives and cables, and run out of USB ports? And if my primary drives were all internal, I wouldn’t have to unmount and unplug them when packing up the Mac—just close the lid and they go to sleep. A larger screen would also make it a better second display in my office.
In other words, if there’s a MacBook that tries to be as close as possible to an iPad, there should be one that’s as close as possible to a desktop Mac. Although Apple no longer has any desktop Macs with lots of internal storage options, either…
Update (2016-02-08): Jean-Louis Gassée:
Despite these improvements, the iPad Pro is (still) not a laptop replacement. Actually, for my uses, it’s the other way around. The new, light Retina MacBook (935 grams, 2.06 pounds) I bought when it came out last March has taken screen and lap time from my iPad.
Whether it’s the operating systems or the core apps, a major aspect of what makes both users and reviewers value Apple products is software that melds power, reliability, and ease of use. “It just works!” was a favorite Steve Jobs phrase.
In the last couple of years, however, I’ve noticed a gradual degradation in the quality and reliability of Apple’s core apps, on both the mobile iOS operating system and its Mac OS X platform. It’s almost as if the tech giant has taken its eye off the ball when it comes to these core software products, while it pursues big new dreams, like smartwatches and cars.
In response to my inquiries about this, Apple said: “We have dedicated software teams across multiple platforms. The effort is as strong there as it has ever been.”
iTunes is once again bloated, complex, and sluggish. That has gotten even worse since the recent integration of the new Apple Music streaming service.
In my experience, on both platforms, Mail is slow at both receiving and sending Gmail messages, whether they are from personal or business accounts. Some messages don’t show up. Search misses things.
iCloud Photo Library, which stores all your images in the cloud, tarnishes the improved experience. It works quickly and accurately on my iPhone and iPads, but is slow and balky on the desktop. I am not one of those people with 50,000 or 100,000 pictures, but it still takes forever on the Mac to find older photos, and some show up as just blank thumbnails. That isn’t Apple quality.
My Safari bookmarks only sync intermittently across my Apple devices. Unlike Amazon’s Kindle app for Apple products, the company’s iBooks doesn’t remember where I left off unless I set a bookmark.
There are only three reasons I can think of that software issues like the ones we find in Apple Music would happen at a company like Apple that prides itself on software that “just works.”
They didn’t know how bad it was when they released it. (Highly unlikely)
They are so big now, they just don’t care. They are Apple, so people will use the software regardless of what they do. (Please don’t let it be this one)
They were given a timeline to release the software whether it was finished or not. (This one is probably, but very scary)
Maybe this is the natural result of the fact hardware standards must be high, because they can’t issue “hardware updates” over the air like they can with software. But the perception is now widespread that the balance between Apple’s hardware and software quality has shifted in recent years. I see a lot of people nodding their heads in agreement with Mossberg and Dalrymple’s pieces today.
That we’re still talking about it a year later — and that the consensus reaction is one of agreement — suggests that Apple probably does have a software problem, and they definitely have a perception problem.
My little iCloud Photo Library syncing hiccup was not a huge deal — I was even lucky insofar as the two videos that couldn’t be found were meaningless. And I managed to find a solution. But it feels emblematic of the sort of nagging software problems people are struggling with in Apple’s apps. Not even the bug itself that led to these five items being unable to upload, but rather the fact that Photos knew about the problem but wouldn’t tell me the details I needed to fix it without my resorting to the very much non-obvious trick of creating a Smart Group to identify them. For me at least, “silent failure” is a big part of the problem — almost everything related to the whole discoveryd/mDNSresponder fiasco last year was about things that just silently stopped working.
I clicked OK and the Free button was now inactive. I typed Command-R to see if that would reload the iTunes page—no normal user would do it, but it worked because the App Store and iTunes is more or less a disguised web page—and then was able to click Free and download the app.
At some point in this process, the song I was listening to finished and another song began to play. It was a randomly selected track from my entire music library. The act of viewing the App Store had destroyed my music shuffle.
This is what Walt Mossberg means by “I dread opening the thing.”
Ever since I upgraded (cranks are reminded to add their air quotes here) to El Capitan, dragging something towards the top of the screen is an exercise in frustration, and dragging something to the menu bar in order to cancel the drag is a gesture set in muscle memory that I’m struggling to unlearn. Whenever you get close, Mission Control springs to life. Mission Control is great, if you have five windows open. If you have between 10 or 20 apps open and several of them have state-restoration, let’s-restore-everything, Quit-doesn’t-mean-clean-slate endless amounts of windows, it is an exercise in chugging. It takes half a minute, then you get one frame. It takes ten seconds more for the next. This is a MacBook Pro Retina (Early 2015), so it’s not a 2011 Mac mini with low memory and a slight limp.
Add to this storing all these Numbers documents in iCloud because I might need them one day on my iPhone. Then I do need them, and I open Numbers on my iPhone, and 30 documents start syncing now for the first time, and none of them get anywhere, and there are several duplicates, and I can’t even tell it which to download first, not that it matters because like I said, none of them fucking progress in the slightest.
This is not Haxies. This is not jailbreak. This is not unsandboxed, unencrypted, uncryptographically signed. This is Apple’s own software running on Apple’s own OS, running on Apple’s own hardware, talking to Apple’s own fucking internet services the way Apple pretend it just works if you do.
I’ll add one more to the mix: since watchOS 2.0, I haven’t been able to launch native third-party apps on my Watch. Apps from TestFlight work fine, as do WatchKit apps, but native third party apps continue to experience an issue associated with the FairPlay DRM that prevents them from loading — they simply crash at launch.
As I wrote in one of the bug reports I filed on this, I cannot believe watchOS 2 launched in this state.
On OS X this is especially true: OpenGL implementation has fallen behind the competition, the filesystem desperately needs updating, the SDK has needed modernizing for years, networking and cryptography have seen major gaffes. And that’s with regards to the under-the-hood details, the applications are easier targets: it’s tragic that Aperture and iPhoto were axed in favor of the horrifically bad Photos app (that looks like some Frankenstein “iOS X” app), the entire industry have left Final Cut Pro X, I dare not plug my iPhone in to my laptop for fear of what it might do, the Mac App Store is the antitheses of native application development (again being some Frankenstein of a web/native app), and iCloud nee MobileMe nee iTools has been an unreliable and slow mess since day one.
What worries me is that AAPL the stock ticker and Apple the company are in a (self-driving) crash course with one another: AAPL needs to launch new products to drive growth and Apple needs to improve the products that have already shipped. The most valuable asset that Apple own is their brand, and that’s the brand that’ll drive sales of any car that may or may not be in development. If that brand name is tarnished by regressions and performance problems, what consumer would buy a car from the brand?
I’m still encountering many of the original El Capitan bugs. And I’m continuing to run into new issues. This week it was AppleScript in Numbers, AirDrop no longer working between my Macs, and the Xcode 7.2.1 update that broke the Bots feature.
See also: Accidental Tech Podcast.
Previously: Apple’s Software Quality, Continued.
Update (2016-02-08): Katie Floyd:
Mossberg discusses his piece in more depth on his podcast this week, it’s worth a listen.
Update (2016-02-13): On The Talk Show, Eddy Cue and Craig Federighi discuss Apple TV, Apple software quality, iTunes, Apple Maps, and Radar. I found this frustrating because they kept talking about how, by their metrics—which sounds like number of crashes—quality is better than ever. Any perceived quality decline is due to Apple operating at a larger scale or people missing old iPhoto features, rather than actual bugs. MobileMe had problems, but that’s in the past; iCloud is reliable. The fact that 200K iMessages are sent per second doesn’t make me feel any better about the ones I send or receive not getting through. They haven’t made major changes to iTunes because people are attached to the way it works, yet they had no problem throwing Aperture users under the bus when they thought Photos was the way to go.
A lot of my research depends on PDFs, so Preview’s excellent features for highlighting and annotating them make it a must-use. But Preview crashes all the time. It commonly freezes or shuts down, sometimes taking the entire computer with it, when asked to render pages that Adobe Acrobat reader, the leading third-party PDF program, handles with ease.
Preview users have been pleading with Apple for years on the company’s user forums to fix Previews’s propensity for crashing. But Apple has failed to do so, or even to acknowledge the complaints, over three or four successive releases of new operating systems.
Conjectures about why Apple can’t get its software act together abound. The most common is that the company has become so trapped in its cycle of annual hardware upgrades -- a new iPhone had better appear every September, or else -- that it’s simply incapable of keeping its software maintained.
I guess Federighi doesn’t consider iTunes and Mail to be core software. For more than five years, my daily use of Mail has been plagued with bugs.
Failure of a design feature to work as advertised is one thing, but unprovoked random jumping is another. At least once a day, the dock will just randomly jump to a different monitor when the pointer is nowhere near the bottom of the screen. That’s irritating.
This is a bug that was introduced with Mavericks and has persisted not just through minor dot releases, but through Yosemite and into El Capitan. More than two-and-a-half years later, it’s still annoying me on a daily basis.
That’s an almost unimaginable amount of data, and to expect all iCloud services to work perfectly all of the time over every connection type is clearly unrealistic. All the same, I don’t think it’s unreasonable to complain when sometimes a Note that has existed for years is suddenly and persistently unavailable on one of my devices, and that on numerous occasions, editing a note that is available will duplicate, rather than edit, the note on another device.
Update (2016-02-17): See also: Accidental Tech Podcast 157.
For some time now I get every text message in duplicate on my iPhone, a few minutes apart So does my wife. A “little thing”, but something that really undermines the value of messages and wastes my time and attention. iCloud is a serious problem because I get doubled-up address book entries, dead people returning to my address book, etc. My iPhone demands I “sign in to verify my identity” every day (often multiple times) at the worst possible time: when I want to use the phone (for things having nothing to do with sign in). Sometimes Apple randomly breaks critical functionality like personal hot spot. The iPhone gives an error alert every time I turn off call forwarding. The list goes on. So Apple Core Rot in iOS disrupts the value of the iPhone every day. The iPhone is now only half useful to me, really a mixed bag of usefulness and headache-inducing problems.
Apple Core Rot will only worsen with these clowns in charge: if you can’t see the issues and worse you’re in full-throated denial, they won’t be addressed. In MPG’s view, the problems now runs so deep that we are not talking about a few bugs; we’re talking about structural and leadership problems.
I am a power user and software developer, and I know a lot of Mac users, most of whom are regular, non-techie people. I don’t know a single one who isn’t experiencing crippling frustrations of one sort or another with their Macs, and some with their iOS devices too (although I am going to focus on the Mac). Apple’s hard-earned reputation may have drawn many of these people to use Macs in the first place, but no amount of public relations and manipulation of perception cannot wave away the troubles they are experiencing.
Each OS X release has brought strongly-marketed, but mainly undercooked new features that disrupt long-held user processes. They’ve swapping out mature software willy nilly for unfinished and incomplete replacements. They’ve ignored bugs and glaring, productivity-subverting shortcomings for years.
Update (2016-02-23): See also: The Talk Show with John Gruber and Jim Dalrymple.
Update (2016-03-02): Mark Rogowsky:
Where Federighi went next, however, was on something of a series of tangents. He noted people are just flat out using their devices more, creating higher expectation. He explained Apple has internal metrics that measure software quality and said “I know our core software quality has improved over the last 5 years. Improved significantly.” But those metrics are about things like frequency of apps crashing not absolute numbers of users experiencing miserable software bugs. And here, Apple launched a defense that’s going to frustrate people struggling with some flaw in iCloud or iTunes.
Update (2016-03-14): John Siracusa suggests a different strategy for the Mac.
Update (2016-06-26): In Debug #81, Don Melton recalls texting Craig Federighi to get his iPad unbricked.
The idea of Massive View Controller all started from one simple tweet. It feels like the most obvious and pressing issue in terms of code quality in our industry.
These techniques won’t solve Massive View Controller on their own, but taken together, but they will take you a lot of way there.
Instead of rejecting view controllers, what if we embraced them? We could make lots and lots of small view controllers, instead of lots of lots of small plain objects. After all, Apple gives us good ways to compose view controllers. What if we “leaned in” to view controllers? What benefits could we gain from such a setup?
We have a general principle that we like to follow: prefer composition instead. Luckily, Apple gives us a great way to compose view controllers, and we’ll get access to the view lifecyle methods too, for free! Even if your view controller’s view is totally invisible, it’ll still get the appearance callbacks, like
The letter shapes of Highway Gothic weren’t ever tested, having never really been designed in the first place. “It’s very American in that way — just smash it together and get it up there,” says Tobias Frere-Jones, a typographer in New York City who came to the attention of the design world in the mid-1990s with his Interstate typeface inspired by the bemusing, awkward charm of Highway Gothic. “It’s brash and blunt, not so concerned with detail. It has a certain unvarnished honesty.”
The standard FHWA typefaces, developed in the 1940s, were designed to work with a system of highway signs in which almost all words are capitalized. The designers of Clearview sought to create a typeface adapted for mixed-case signage, initially expecting it would be based on an existing European sans-serif typeface. Instead, using a similar weight to the FHWA fonts, a new font was created from scratch. Two key differences are much larger counter spaces, the enclosed spaces in letters like the lower case “e” or “a”, and a higher x-height, the relative height of the lower case “x” to the upper case “X”.
Though research initially gave us hope that Clearview would make signs easier to read from greater distances and at night, years of additional research have not supported this conclusion.
Early successes we noted were credited to the new font, but the years since have shown those successes were likely due, at least in part, to the fact that older, worn signs had been replaced with new, cleaner ones using brighter materials. After more than a decade of analysis, we learned that retro-reflective sign sheeting materials that direct a vehicle’s headlamp beams back to the observer were the primary determining factor in improved nighttime visibility and legibility.
Among other things, we also learned that Clearview compromises the legibility of signs in negative-contrast color orientations, such as those with black letters on white or yellow backgrounds like Speed Limit and Warning signs.
The ideas behind Clearview sound good, but I do not find it very attractive, and I think the spacing looks weird.
David Sparks interviewed me about my iPhone home screen.
Because we were German, we were very much about implementation. Making sure you had rules that you could actually follow, because it was monolithic. There was no internet. The English were good at concepts, and then they lost it. That’s actually a good combination, the English with their creativity and their weird ideas and then you get a German to make it work. To tighten all the bolts. […] We’re not creative in Germany; we’re good at making things. Too good. We always make things 120 percent. You buy anything from us, it’s always over-engineered.
I did some work for Apple in ’86, ’87. I got the first LaserWriter as payment, which at the time was like 20,000 marks. It was more than a Golf, the car.
There are physical limitations as to certain size. It’s nice to read 10 words a line, 50 to 60 characters. This is science. This is not me. This is something that we like, the way our eyes move in little segments. There are physical limitations to our eyes: the curvature of our eyeballs, the space we have in front of us, the distance from the eyes. That’s human, and no machine can ever change that.
I open [the paper version] and I find things that I wasn’t looking for. On the screen, you have to have a hierarchy, because you can’t fit so much. You have to look for something. Whereas I open the [printed] page and I will find something I wasn’t looking for, I would have never looked for. I wouldn’t know what to look for. I find things that I wasn’t expecting, and that is enriching.
Mobile fonts are doable, but for some reason are behind there. […] It’s ignorance, because these are engineering companies. Essentially, so is Apple. Jony is a mate of mine, and he is a good designer, but he is more of an engineer. He is surrounded by these kids in their twenties, and they go for whatever is trendy. For some reason there is nobody in management to tell these guys to go to us for some advice.
If you need an array of reference types and the array does not need to be bridged to
Sometimes COW can introduce additional unexpected copies if the user is not careful. An example of this is attempting to perform mutation via object-reassignment in functions. In Swift, all parameters are passed in at +1, i.e. the parameters are retained before a callsite, and then are released at the end of the callee. This means that if one writes a function like the following […]
amay be copied despite the version of
awithout one appended to it has no uses after
append_onedue to the assignment. This can be avoided through the usage of
The compiler can only specialize generic code if the call site and the callee function are located in the same compilation unit. One trick that we can use to allow compiler to optimize the callee function is to write code that performs a type check in the same compilation unit as the callee function. The code behind the type check then re-dispatches the call to the generic function - but this time it has the type information.
Swift classes are always reference counted. The swift compiler inserts code that increments the reference count every time the object is accessed. For example, consider the problem of scanning a linked list that’s implemented using classes. Scanning the list is done by moving a reference from one node to the next:
elem = elem.next. Every time we move the reference swift will increment the reference count of the
nextobject and decrement the reference count of the previous object. These reference count operations are expensive and unavoidable when using Swift classes. […] In performance-critical code you can use choose to use unmanaged references. The
Unmanaged<T>structure allows developers to disable automatic reference counting for a specific reference.
When compiling with ARC, method arguments often appear to be retained at the beginning of the method and released at the end. This retain/release pair seems superfluous, and contradicts the idea that ARC “produces the code you would have written anyway”. Nobody in those dark, pre-ARC days performed an extra retain/release on all method arguments just to be on the safe side, did they?
When the compiler doesn’t know anything about the memory management behavior of a function or method (and this happens a lot), then the compiler must assume:
- That the function or method might completely rearrange or replace the entire object graph of the application (it probably won’t, but it could).
- That the caller might be manual reference counted code, and therefore the lifetime of passed in parameters is not realistically knowable.
Given #1 and #2; and given that ARC must never allow an object to be prematurely deallocated, then these two assumptions force the compiler to retain passed in objects more often than not.
This is a general concern of mine in Swift: how to actually know what has value vs. reference semantics.
var, which fixes one problem. But there is no way to see what is a
struct or a
class, which adds another. It’s even more complicated in the context of the proposal to remove the “NS” prefix from Foundation class names.
As an example, the seemingly similar
CountedSettypes produce different results from nearly identical code. Swift’s Set type has value semantics, so changes to a copy don’t affect the original Set instance […]
NSCountedSet), on the other hand, uses reference semantics, so changes to a copy of an instance. This is true whether the copy is an explicit one made via assignment or the implicit copy made when calling a function with
CountedSetas a parameter. This example shows how nearly code nearly identical to the above produces very different results […]
The problem of requiring HTTPs in less than 140 chars: 1.Few benefits for blog-like sites, and 2. The costs are prohibitive.
There’s actually a #3 (sorry) -- 3. For sites where the owner is gone the costs are more than prohibitive. There’s no one to do the work.
Here’s a ten-minute podcast summarizing where we’re at with Google and Mozilla and HTTPS.
Your Kindle will soon receive a free, over-the-air software update. Readers are always looking for their next favourite book, and this update provides new ways to help you easily find new books and new authors that you’re sure to love.
Our readers’ most-used settings—such as Aeroplane Mode and Device Sync—can now be found together with just one tap on your toolbar.
All this looks like Amazon is desperately seeking to shore up ebook sales. Instead of letting you see just your books on the home screen, you have to pass through a vestibule displaying items to buy. Instead of only going to Amazon to search for books when you want, you’ll be exposed to more books each time you visit the home screen. You can naturally then see just your books, but it’s another tap, after your eye has been caught by the books at the bottom of the display.
If you go to advanced options in the updated Kindle software, you can disable the new opening screen entirely. That way when you turn on the Kindle, you see the old list format as before (but in the new, lighter typeface).
Update (2016-02-03): Jason Snell:
Fortunately, you can turn off recommendations, which I did. The fancy graphics disappear when you do this, but the entire interface has still been overhauled. There’s a new typeface that’s absolutely gorgeous on the high-resolution screen of my Kindle Voyage.
But with value types, there’s no
overridekeyword to help the compiler find my mistakes. This omission seems out of place in a language otherwise designed to include enough redundancy to help find one’s errors.
All that can be known at compile-time is that pie is a
Pizza, and the
Pizzaprotocol extension says Wheat, so the declaration of a cornmeal crust in the
CornmealPizzastructure had no effect whatsoever when asking pie for something. Although the compiler could have warned about the potential for error from this use of static- instead of dynamic-dispatch, it did not. I believe that here lurks a trap for the unwary, and I would call this a major snare.
Presenting Swift with both a declaration and a definition in this fashion causes the compiler to take notice of the runtime value of the pie variable.
However, without editing the source code in the framework, we cannot fix this problem. Hence, it is impossible to safely extend a protocol declared in another framework (without gambling that it will never need dynamic-dispatch.)
As shown in a previous section, a declaration in a protocol was sufficient to induce dynamic dispatch for a defined of the corresponding attribute in the protocol extension. But a definition in a restricted extension is always statically-dispatched.
Avoid assigning the result of an expression with side-effects to left-hand-side with optional chaining.
In-out parameters do not work when passed into the outer scope of a closure
These are all things we hope to remove or provide diagnostics for in 3.0, at least.
Swift for all its newness is going down a path much like C++ did as far as complexity. That is worrisome.
Swift’s init rules are confusing. I’ve never once got anything non-trivial right first time
Apple’s new Swift language has taken a page from the C++ and Java playbooks and made initialization a special case. Well, lots of special cases actually. The Swift book has 30 pages on initialization, and they aren’t just illustration and explanation, they are dense with rules and special cases.
The initializer model does need reconsideration, though. Current model doesn’t fit our ABI resilience goals.
A little up-front complexity for initializers greatly simplifies the state space for everything else.
Let’s sum up everything to that point:
- AppCast process is using HTTP that could be intercepted and modified on the fly
- We control the transmission after doing the MITM attack
This attack works on stock Mac OS X install, and GateKeeper enabled with both options “Mac App Store and identified developers” or “Mac App Store” (the strictest one).
I’m not going to explain the details of his attack, his post is quite self explanatory, but I’ll show you how easy it is to mass pwn OSX machines on your network using the new OSX Sparkle bettercap proxy module.
Moreover, I improved the attack ... Radek shown how to get RCE using an OSX terminal profile file, I will show you how to make the target execute any Mach-O executable you want!
Update (2016-02-02): Rosyna Keller:
That is, Sparkle was explicitly opening every file using LaunchServices by overriding the default WebView handler.
Update (2016-02-10): Dan Goodin:
Fellow researcher Simone Margaritelli has developed a technique that streamlines the attack by allowing it to work with the Metasploit exploit framework. He showed how he could exploit the vulnerability on a fully patched Mac running the latest version of the VLC Media Player. VLC developers released an update three days ago that patches the vulnerability so that the attack no longer works against the latest version.
The precise number of apps affected isn’t known because it’s not easy to detect all the conditions necessary for them to be vulnerable. Radek estimated the number to be "huge" and said he has confirmed that the list includes Camtasia 2 v2.10.4, DuetDisplay v184.108.40.206, uTorrent v1.8.7, and Sketch v3.5.1. Computer forensics expert Jonathan Zdziarski told Ars that the Hopper reverse engineering tool and DXO Optics Pro are also susceptible. A longer list of apps that rely on Sparkle is here, but readers are cautioned that not all of them communicate over insecure HTTP channels or use a vulnerable version of the update framework. Margaritelli said the most recent version of the Adium instant messenger uses HTTPS for updates and isn’t vulnerable.
Sparkle has released a fix in the newest version of the Sparkle Updater, but it will take some time for Mac apps to implement the patched framework.
Update (2016-02-16): Josh Centers:
If you are still worried, how do you figure out which apps are vulnerable? People have offered all sorts of Terminal commands to suss out vulnerable apps, but the best one I’ve found comes from RussW, a commenter on Mac Kung Fu. His solution checks to see if the app uses both Sparkle and an insecure HTTP connection, and then it prints out a list of those apps in a fairly readable format.
Unfortunately, there are smart quotes in RussW’s text that partially break the command (thanks to reader Joe for pointing that out), so I’ve created a Pastebin link with the properly formatted command. Follow that link, copy the command under RAW Paste Data, paste the command in the Terminal window, and press Return. Terminal will list the vulnerable apps in your Applications folder.
This is a fine idea, but when I upgraded, I was surprised to find that the new “All Vaults” view is the default view. Even when I selected a specific vault as my preferred view, the next time I launch 1Password from my browser it would revert to the “All Vaults” view. I found this very irritating. This change struck me as wrongheaded—it flies right in the face of how I use vaults, as I prefer to keep each group of passwords segregated from the others.
That was my reaction as well.
Sell outside the Mac App Store to increase revenue per sale and get to know your customers. This book shows you how. Fully functional, super-clean coded sample apps, everything ready to be copied right into your project, backed by more than 200 unit tests in total!
Save days of research and start selling your app before an Apple review person would even notice your upload to the App Store.
Since then, only on VLC, we've had around,
- 700 contributors,
- 70000 commits,
- at least 2 billion downloads,
- hundreds of millions users!
And all that, mostly with volunteers and without turning into a business!
A little know fact about the VideoLAN project is that it was started so that the student organization could justify the need to replace the old networking infrastructure of the campus with a brand new high-bandwidth fiber optics network. They really wanted to deploy a fiber optic network but the school would have never approved it so they thought “OK, we need something that uses a ton of bandwidth, let’s make a video streaming app”.
They proceeded to start the VideoLAN project, with the VideoLAN Client (VLC) and VideoLAN server, and streamed movies and public television channels to the whole campus.
It remains frustrating to me that VLC can play (just about) everything but only in its own app, while QuickTime works in every app but doesn’t support many popular formats. For a while, QuickTime plug-ins seemed to be the solution, but Apple doesn’t want to support them anymore.
Previously: Perian to Cease Development.