Anecdotally speaking, I hear from several low vision iOS-using friends who lament the default system keyboard, which is essentially the same keyboard that shipped with the original iPhone in 2007. The problem, my friends say, is that the key caps are too small and the glyphs too hard to read. With the new API, though, third party developers such as the team at Fleksy can create entirely customized keyboards that users can use instead of the stock one. This means developers can control key spacing and size, color, and so forth in an effort to create keyboards that accommodate for a wide array of visual — and motor — needs.
Archive for June 2014
When they turned to me, I was also initially puzzled, because all this should do on x86 is stuff a zero into %eax and return. This cannot possibly crash, so everyone just assumed that the stack traces were off, as they frequently are.
Fortunately I had just looked at the project settings and noticed that we were compiling with -O0, so optimizations disabled, and my suspicion was that ARC was doing some unnecessary retaining. That suspicion turned out to be on the money,
otool -Vtrevealed that ARC had turned our innocuous
return NO;into the following monstrosity.
I think you pretty much have to use the optimizer when using ARC. Otherwise, in normal use the code is really slow, and when debugging it’s so different from the normal code that you will be checking different things.
For a while now, many of you have been asking for a better way to access data to build apps that integrate with Gmail. While IMAP is great at what it was designed for (connecting email clients to email servers in a standard way), it wasn’t really designed to do all of the cool things that you have been working on, which is why this week at Google I/O, we’re launching the beta of the new Gmail API.
Designed to let you easily deliver Gmail-enabled features, this new API is a standard Google API, which gives RESTful access to a user’s mailbox under OAuth 2.0 authorization. It supports CRUD operations on true Gmail datatypes such as messages, threads, labels and drafts.
Just confirmed with right people: IMAP remains fully supported and isn’t going away.
The Gmail API should not be used to replace IMAP for full-fledged email client access. Instead, see IMAP and SMTP.
Ole Zorn quotes the App Store Review team:
Your app, Pythonista (528579881), has been removed from the App Store due to an unresolved issue.
He seemingly had no idea what this issue was, having recently removed some features from the app and had it approved again.
Thank you for contacting the App Review Board. The app is now for sale on the App Store.
There was apparently no explanation or apology.
The App Store is nearly six years old. It is still hostile to developers. I see no evidence that Apple even recognizes that there’s a problem. Android is finally forcing Apple to respond with more screen sizes and extensibility, but the Google Play Store doesn’t seem to be applying much pressure.
This looks like a great upgrade to xScope. The text and mirror features are particularly interesting. I do not find xScope’s interface very intuitive, but it comes with good documentation. I suspect that once I really learn how to use it I’ll get a lot more out of it. The Mac App Store version is currently half the price but has limitations due to sandboxing. Purchasing the Mac App Store version does not seem to activate the direct version.
Apple introduced Swift as “Objective-C without the C”, but in many ways, Swift is closer to “C++ without the C” (or Objective-C without the Smalltalk). Swift’s generics, for example, are closer to C++’s templates than to any feature of Objective-C. One of the more subtle ways that Swift resembles C++ is in how it calls methods. Unlike Objective-C, where methods are called using message passing, Swift uses a vtable for method dispatch, and when the compiler has enough information, inlines the function call directly. While this improves performance over message passing, it trades power and flexibility for performance gains that aren’t necessary for most apps.
In this article, I will present use cases which are currently impossible or difficult to implement without message passing.
Objective-C isn’t going away any time soon, but if Swift succeeds in becoming the dominant language for iOS and Mac development, Objective-C will go away. Eventually the cost of maintaining two languages and runtimes will cease to be worth it. Like Carbon before it, Objective-C will be deprecated, leaving Swift as the only supported language for app development on Apple platforms. In general, I am loathe to argue that my way is the one true way to do things, but since Swift will eventually be the one way to do things, and since now is the time when large changes will be easiest to introduce, I feel compelled to argue that Swift should forswear all but message passing.
On the Mac, swizzling is used to implement plug-in functionality, even for apps that don’t have a plug-in API. This adds features that are very important to power users. Many popular Photoshop and Xcode plug-ins use method swizzling. GPGMail, a plug-in for Mail.app which adds OpenPGP encryption to Mail.app, makes extensive use of method swizzling. This functionality is incredibly important to security-minded individuals, especially in the wake of the Snowden leaks. If Mail.app were rewritten in Swift, this would not be possible.
Swift already does have a way to opt-in to message passing, it’s called the @objc flag (and performSelector:). It works fine, but it’s extra work to opt into it and use it. But, I don’t think that’s bad given that it disables so many useful optimizations.
What may be bad is that the name “@objc” is a dead giveaway that this is a feature with a deprecation date. So I think we need some other, reflectionish system going forward.
My argument is that Swift will be primarily used to write high-level apps. For these apps, message passing is almost never a bottleneck. Swift is not going to replace the optimized C and C++ code, especially for the really low-level stuff.
But even if Apple does decide to rewrite all the Core* frameworks et. al. with Swift, there’s still an argument that Swift should use message passing by default, and a way to opt in to vtable and direct dispatch for performance-critical code. For higher-level apps, message-passing is a lot less useful if it’s opt-in.
To me it looks like replacing ObjC and the frameworks (over time) and the style that puts everyone on an equal footing. So instead of having a language where anyone can build something like Core Data, you will have a language with built-in support for Core Data. Apple’s Core Data, that is, and you will like it. Just another tightening of the screws (App Store, App Store–only APIs despite promises).
In the rare occsion that objc_msgSend is a bottleneck in an Objective-C app, there are techniques like IMP caching that can improve performance, and that’s really the kind of thing I’m advocating here. Give developers some way to opt in to vtables when there’s a real performance problem, but allow the greater flexibility of message sending by default. It’s possible to start with message passing and optimize when needed, but it’s not possible to start with vtable dispatch and use message sending when needed.
Message sending allows many problems to be solved with much less code. This increases programmer producivity and lowers maintenence costs. Since message sending is fast enough in most cases, the end user sees no difference between vtables and message sending, so Swift should use the solution that results in better programmer productivity.
Apple introduced a new Photos app during its Worldwide Developers Conference that will become the new platform for the company. As part of the transition, Apple told me today that they will no longer be developing its professional photography application, Aperture.
Apple was very clear when I spoke with them this morning that development on other pro apps like Logic Pro and Final Cut Pro is continuing. Professionals in those app categories should not worry about their apps—they will continue as normal.
I would have thought that Final Cut Pro X was the warning to video professionals. Apple may care about a particular product category, but it seems to have little regard for files, AppleScript workflows, or plug-ins that professionals (or even prosumers) rely on.
The Photos app, previewed at the 2014 Worldwide Developers Conference, will become the company’s main photographic focus for both professionals and consumers. As it grows, Apple intends the single app to serve the needs of both consumers and professionals. (That will be an interesting challenge; it will be intriguing to see how Apple puts all of its photographic eggs in a single basket.)
The same will be true on the iOS side, where the mobile iPhoto app will disappear and the Photos app will become the focus of Apple’s photography-related app development when iOS 8 is released in the Fall.
It was not explicitly said, but it seems clear that this consolidation will come at the expense of the professional features.
The new Photos app will include many of the advanced features contained within iPhoto and Aperture, but also offers the big advantage of syncing with iCloud Photo Library, which will sync every photo you take when iOS 8 and OS X Yosemite ship later this year.
One of the best parts of Aperture is its filing system and storage options. The focus of the Photos app is the cloud. I doubt local storage features will make the cut. I’m guessing that by “advanced features” Apple does not mean offline images and masters stored across multiple drives, but rather “some of the editing controls that are not in iPhoto.”
Apple says that it will provide compatibility updates to Aperture that allow it to run on OS X Yosemite, but will not continue to develop it. Adobe says that it will ‘double down’ on Lightroom support and offer Apple users a way to migrate.
Article updated to clarify that there is no official workflow for migrating to Lightroom.
I tried Lightroom early on but much preferred the way Aperture was designed. I still really like Aperture, even with lack of updates. Part of the appeal of apps like Aperture is that your whole edit history is stored. Now that is likely lost, along with the GPS tracks that I imported. I don’t see how much can be migrated to Lightroom, which has a different engine for applying adjustments—and also a different data model in other respects.
Put simply we’re doubling down on our investments in Lightroom and the new Creative Cloud Photography plan and you can expect to see a rich roadmap of rapid innovation for desktop, web and device workflows in the coming weeks, months and years. We also continue to invest actively on the iOS and OSX platforms, and are committed to helping interested iPhoto and Aperture customers migrate to our rich solution across desktop, device and web workflows.
We’re working on a way for iPhoto and Aperture customers to more easily migrate to Lightroom. As of right now, your best bet is to save any metadata to your files, then import the files directly from disk. (Note: Aperture develop settings aren’t compatible. If you want to preserve the look of your image edits, export rendered versions of your files from Aperture to import to Lightroom).
That’s what I was afraid of.
When the groundbreaking Lamborghini portable ash tray/coin receptacle ships next year, Lamborghini drivers will be able to migrate their existing pennies and/or cents. Lamborghini’s well-known track record in ad-hoc loose small-denomination currency storage and management is unparalleled and unrepentant.
When asked about what Aperture-like features users can expect from the new Photos app, an Apple representative mentioned plans for professional-grade features such as image search, editing, effects, and most notably, third-party extensibility.
I mean, the new Photos app is really impressive, but it’s not Aperture. It absolutely looks like a valid replacement for iPhoto, but not Aperture. I could switch to Lightroom, but I hate its editing workflow.
Meanwhile, in the real world, the announcement that Aperture was dead, and that Apple was effectively abandoning professional photography, appeared via Jim Dalrymple’s blog. Aperture remained on sale in the App Store while muddled Apple clarifications showed up in various blogs. Some said saying there would be support through Yosemite, others hinted at helping Adobe with migration to Lightroom. As end-of-life announcements go it was a complete screw-up.
As of today none of my 20,000 or so non-destructive image edits will convert to Lightroom, much less album/image relationships, image/project, folder/image/project, folder/project comments, geo-tags and more.
The way Apple executed Aperture’s termination is a rich lesson in the consequences of data lock (a risk I understood when I signed up with iPhoto long years ago).
You’d think they’d have learned after the Final Cut Pro mess and the iWork mess how to make these announcements.
The issue isn’t Apple killing a dying product. Rather the issue fundamentally is why people should trust Apple with their data when they’ve pulled this three times in a row.
Update (2014-06-30): There are more comments from TidBITS readers.
Update (2014-07-06): Jeff Carlson:
Apple has a notorious history of clear-cutting old software to make room for new in this way. iMovie, for example, gained a brand new approach with iMovie ’08, but didn’t catch up to the previous version’s feature set for a couple of revisions. And many Final Cut Pro users are still hanging onto their editing systems three years after the introduction of Final Cut Pro X. The ones who did make the switch wisely completed projects in the old version and reserved Final Cut Pro X for use with new projects.
With photos, however, you can’t just disregard old photos and move forward with the new, unless you’re willing to make a clean break and risk that your old library may become inaccessible. Part of having a photo library is to be able to reach into it to find old images. Abandoning a mature application like Aperture, where users probably manage thousands or tens of thousands of images, is complicated.
Chances are, unless Apple has really spent all this time building a deep application while ignoring Aperture and iPhoto, Photos for OS X will fall down in one or more of those areas. (I’d love to be proved wrong.) But Apple’s pattern of re-engineering applications and releasing them with core — not comprehensive — functionality doesn’t make me optimistic.
“Wow, we’re gonna have a lot of mad customers. But, hell, what are they gonna do? It’s easier to change gender than to move from Aperture to Lightroom — and Adobe ain’t gonna last much longer anyway. There’s no money in pro software, and they got nothing else.”
Are pro needs really different from consumer needs in still photography? I’ll venture that they are not.
Update (2014-07-11): Jeff Carlson:
No matter what’s to come, you can start to take steps now to prepare for your transition—whether that means switching to Photos or migrating to another third-party photo application.
Debug is a casual, conversational interview show featuring the best developers in the business about the amazing apps they make and why and how they make them. In part 2 of the Nitin Ganatra trilogy, the former Director of iOS apps at Apple talks to Guy and Rene about working on Mail for OS X, and the early days of Purple, the experience project that would ultimately deliver the iPhone.
Previous reports had described a competition between P1 (the iPod-phone developed by Tony Fadell’s team) and P2 (the OS X–phone) as though Apple waited a long time to decide which way it wanted to go. Ganatra makes it sound as though P2 was always what Apple wanted to do, and P1 was only there so that Apple would have a stopgap product to ship if P2’s development took too long.
Debug is a casual, conversational interview show featuring the best developers in the business talking about the amazing apps they make and why and how they make them. In part 1 of the Nitin Ganatra trilogy, the former Director of iOS apps at Apple talks to Guy and Rene about his early career in Developer Technical Support (DTS), working on System 7 in the Copland era, and the advent of Carbon.
Up until mid-2010, any rogue website could get a good sense of your browsing habits by specifying a distinctive
:visitedpseudo-class, rendering thousands of interesting URLs off-screen, and then calling the
getComputedStyleAPI to figure out which pages appear in your browser's history.
After some deliberation, browser vendors have closed this loophole by disallowing almost all attributes in
:visitedselectors, spare for the ability to alter text, foreground, and background colors for such links. The APIs have been also redesigned to prevent the disclosure of this color information via
This workaround did not fully eliminate the ability to probe your browsing history, but limited it to scenarios where the user can be tricked into unwittingly feeding the style information back to the website, disclosing information about one URL at a time. Several fairly convincing attack vectors have been demonstrated - my own entry can be found here - but they generally require roughly one click per every visited URL. In other words, the whole thing doesn't scale particularly well.
The practicality of such CSS-based history snooping attacks could be improved greatly if we had a way to design an n-to-2n decoder circuit with the styling elements available on visited links.
I’m not going to claim that my own creative output has any more value than anyone else’s, nor that it’s ‘worthwhile’ in any particular sense. But it’s mine, and it’s thus unique. I think that it’s worth preserving, if only because this particular consciousness – this person – will never exist again. Your work has every bit as much value, and deserves similar preservation.
I’m pleased to announced that Fat Cat Software has acquired FlickrExport from Connected Flow Ltd, its long time home. FlickrExport is a pair of plugins that let you upload your photos and metadata to your Flickr account directly from your iPhoto or Aperture library, using each program’s built-in exporting function. FlickrExport has also been updated to version 4.1, which now provides compatibility with iPhoto 9.5, and fulfills Flickr’s new requirement that all communication with its servers be done over an encrypted SSL connection.
Great news, since both development and support of FlickrExport had seemingly stopped years ago, and the plug-ins were on the verge of breaking.
After 9 months of intense work, we’re very proud to announce a major new addition to FastMail. We’ve taken all the great things about FastMail’s email hosting and applied them to build an awesome new calendar. You get the same incredibly speedy and elegant web interface. The same robust, fully-redundant backend (with live off-shore replicas). The same power behind an easy-to-use interface.
CalDAV support is included on the $40/year plan, with contact support on the way.
Step forward, The NSFetchedResultsController Stress Test. It’s a chaos monkey for pseudo-randomly modifying a simple Core Data model. After each iteration, the fetched results controller is interrogated to see if it’s correctly kept up. You can run the tool for as long as you like, but if there is a bug, it does tend to fail fairly quickly.
If there are multiple animations going on at the same time, they are all sent to the render server and all of their changes are applied to the render tree for each frame being rendered. If there are two (or more) animations for the same property, the first will apply its intermediate value and the next will apply its intermediate value on top of that, overwriting the first value. Even animations that are completed but not removed apply their changes to the layers in the render tree, leading to some unnecessary overhead.
Knowing this, our two cases with the order of the implicit and explicit animations can be explained and visualized as follows.
The best practice is actually to do the same thing as UIView is doing and disable the implicit animation. If we do that, then it doesn’t matter it we update the model before or after.
I am fascinated by the possibilities Swift opens up: we are now able to try, in an idiomatic way, constructs that would have been strange and out-of-place in Objective-C. I think they’re exciting, and definitely worth exploring.
So there we have it. A very simple Cocoa app, but put together very differently from a normal Objective-C app. Even if you’ve used Model-View-ViewModel before in Cocoa, odds are you’ve never tried to use completely immutable data structures quite like this. I know I gave up very quickly the few times I considered it, because ensuring immutability actually increased the mental overhead of writing the Objective-C code.
Because the collections use generic types, they have no problem containing
structs. Object members work without difficulty. They basically become pass-by-value objects rather than a totally different entity.
The result is that small model classes become a lot nicer in Swift. How many times have you used an
NSMutableDictionarywith a few fixed keys to represent a bag of related data that really should have been a class? If you’re like me, the answer is “too many”. That’s because making a simple Objective-C class is a bit of a pain.
[The trailing closures feature] is interesting because it knocks down a visual barrier separating language constructs from library calls. As I discussed way back in 2008, blocks are a great addition to Objective-C because they allow you to write your own control constructs. This showed up in a huge way with GCD, which could provide a ton of useful asynchronous calls that worked a lot like language constructs, but were implemented as library calls. However, with Objective-C, there’s still a syntactic difference in how you write calls with blocks compared to how you use built-in language constructs.
As I discussed above, interoperability is technically challenging no matter who attempts it. Apple clearly has the capacity to tackle the technical issues if it really wanted to. The central problem for interoperability is one of motivation. Who has the power to compel all the hospitals and EHR vendors in the US to open up read/write access to their medical records?
First unveiled at the Tokyo MacWorld Expo on February 17, 1994, the QuickTake 100 went on sale 20 years ago from yesterday — June 20, 1994. It was priced at $749 and initiated the age of consumer digital photography.
The QuickTake 100, which captured and stored eight 640 x 480 pixel (or 16 320 x 240 pixel 24-bit color images) was the product of the inventor of the digital camera: Kodak. Afraid of jeopardizing its film business, Kodak didn’t want its own name on its own creation, just one in a long series of digital camera history ironies.
What’s even less known is how that first binocular-shaped digital camera started out 20 years earlier as a toaster-shaped device.
To be clear, iOS 8 will expose just about every manual camera control possible. This means that ISO, shutter speed, focus, white balance, and exposure bias can be manually set within a custom camera application. Outside of these manual controls, Apple has also added gray card functionality to bypass the auto white balance mechanism and both EV bracketing and shutter speed/ISO bracketing.
Sounds good, but I hope the controls work better than the iOS 7 HDR button, which still keeps changing itself back to Auto.
In Swift, we lost this functionality. The reason this was traditionally done with a #define, and not a function or class, is so that we can use the __PRETTY_FUNCTION__, __FUNCTION__, __FILE__, and __LINE__ macros. The preprocessor replaces those macros with their actual values. For example, __FILE__ will always contain the filename where the macro is placed for example. If you were to use them in a logging function, the macros would always contain the information of the logging function, not the calling function, rendering them useless.
How does this work when I said earlier that using __FUNCTION__ and its friends in a function only gives you the information in the function instead of where it’s called? Well, that’s the secret sauce I discovered last week. If you set the default value of a parameter in a function to one of the macros, the compiler fills in that value at the calling location giving us the effect we need. Giving us access to the correct macro values inside the function that’s called.
When you pass a function as an argument of a generic type
<T>, Swift doesn’t pass its raw address directly, but a pointer to a trampoline function (see below) along with some meta information about the function. And the trampoline itself is a part of a structure wrapping the original function.
That the compiler is capable of catching (some) bugs using static type checks is undeniably true. However, what is also obviously true is that not all bugs are type errors (for example, most of the 25 top software errors don’t look like type errors to me, and neither goto fail; nor Heartbleed look like type errors either, and neither do the top errors in my different projects), so having the type-checker give our programs a clean bill of health does not make them bug free, it eliminates a certain type or class of bugs.
[Robert Smallshire] talks about this some more in the talk titled The Unreasonable Effectiveness of Dynamic Typing, which I heartily recommend. However, this isn’t the only source, for example there was a study with the following title: An experiment about static and dynamic type systems: doubts about the positive impact of static type systems on development time (pdf), which found the following to be true in experiments: not only were development times significantly shorter on average with dynamically typed languages, so were debug times.
I previously mentioned the Highpoint RocketStor 5212 (Amazon), which is a dock for dual 2.5- or 3.5-inch hard drives that connects via Thunderbolt. USB 3 has always seemed plenty fast to me for backups, so I initially dismissed the RocketStor and its high price. However, I continued to have problems with hard drives spontaneously unmounting during backups. This would, at the least, interrupt hours of work, and at the worst corrupt the data. In some cases, the only way to complete a backup was with multiple passes of SuperDuper’s Smart Update, each one copying a different set of files before failing, until finally all were copied.
The problems occurred with both the NewerTech Voyager S3 (Amazon) and the Anker USB 3.0 Hard Drive Docking Station (Amazon). It occurred with multiple Macs, multiple (of each) drive docks, multiple hard drives of different capacities and brands, multiple backup apps, multiple uninterruptible power supplies (as well as none), with and without any other connected USB devices (including hubs), and in multiple buildings.
I reported the problem to the manufacturers, who seemed not be aware of it, and received replacement drive docks, which didn’t work any better. I also got some recommendations for other brands, although the Amazon reviews did not inspire confidence.
I still don’t know what’s causing these problems, nor why they only affect some users. However, my hypothesis is that it’s related to USB 3. There may be a bug in the Mac OS X driver, although I’ve seen similar reports from Windows 7 users. Perhaps the bug is with the USB 3 on the docks themselves. In any event, every USB 3 drive dock I’ve tried has had the unmounting problem, and none of my older USB 2 drive docks did. (Unfortunately, USB 2 drive docks are much slower and only support capacities up to 2 TB.)
The obvious solution was to try a drive dock that doesn’t use USB 3. This brought me back to the RocketStor, whose price has come down from $219 to $190. Result: through many hours of backups as well as regular use, the RocketStor has never spontaneously unmounted a drive.
The RocketStor has some other good points:
- It seems to be faster than the USB 3 docks, even though my 3.5-inch drives are not high-performance models and they are encrypted with FileVault 2.
- The power plug isn’t a brick.
- As a dual dock, it has fewer cables and takes up less desk space.
I also found some problems:
- Despite the much higher price—the Voyager S3 is only $37—the RocketStor does not come with a Thunderbolt cable.
- There is only one Thunderbolt port (no passthrough). My MacBook Pro only has two ports, so with an external display and the RocketStor, I can’t connect any more devices. Any additional external storage must connect via USB.
- On the front of the dock is a bright blue light that’s always on, even if no drives are inserted.
- Drives do not always spin down when unmounted.
- There is no power switch, so after unmounting a drive you have to remove it from the dock (or unplug the dock) to actually turn it off.
- Each drive has an eject button, but it almost never works. That is, I can push the button all the way down, and for most types of drives this does not actually move it enough to disconnect it. The drive is still spinning. I reported this issue to Highpoint. They were unfamiliar with the problem and offered a free exchange—I paid return shipping while they cross-shipped—but the replacement RocketStor had the same problem. I’ve taken to pushing the drive’s top corner to the side in order to disconnect it. Then I let it sit, at an angle, for a while so that it fully spins down before I remove it from the dock.
- After booting the Mac, the initial drive insertions work correctly, but sometimes after ejecting one drive and inserting another, the new drive spins up but doesn’t mount. This problem occurred on both my RocketStor and the replacement. The workaround is to unplug and replug the Thunderbolt cable—make sure you’ve first unmounted the drive in the other slot—or to restart the Mac. With recent versions of Mac OS X (now running 10.9.3), this problem occurs less frequently.
All of this is to say that I consider the RocketStor a flawed product, but I’m grateful to have it because once a drive is mounted it stays mounted. Sadly that seems to be a lot to ask of a storage product these days.
Update (2015-05-08): The price at Amazon is now down to $147.
CloudKit makes a refreshing change from iCloud Core Data in that there’s a lot less magic going on in the framework. Using iCloud to sync Core Data is very slick, in that you can essentially treat changes from the cloud as if they had been made on a different thread. Changes get saved, you get notified, and you merge those changes and update the app state. Your code never concerns itself directly with the cloud aspects of its data. That’s when it works, of course. It does appear that iCloud with Core Data works much better than it did when I last tangled with it, but it’s still a magic box that abstracts away all of the work of dealing with the cloud.
In contrast CloudKit is not actually a sync mechanism. Instead it’s a transfer mechanism, where your app must explicitly initiate all data transfers. Starting with the
CKDatabaseclass, your app gets local references to cloud-based databases. CloudKit’s API deals with that database as a specifically cloud-based entity. When new changes are available, you need to fetch
CKRecordinstances and convert them into something that fits your local model. When you have new outgoing changes, you need to create or update the appropriate
CKRecord, again converting data as needed.
As a result, using CloudKit will likely mean more code in your app than using iCloud with Core Data. On the other hand, CloudKit’s more direct and less magical approach to dealing with cloud-based data should be more reliable.
The problem is that given a warning string, it is very difficult to determine what its corresponding warning flag is. Unless a random Stack Overflow question pops up for the given error string, you're pretty much out of luck.
So this week, as a public service, we've compiled a (mostly) comprehensive list of Clang warning strings and their associated flags[…]
The list is also available at an easy-to-remember domain name.
So what’s the real problem here? There are actually two problems that end up causing this issue:
- Arrays are structs and structs have value-type semantics. The entire metadata for the array, such as the startIndex, endIndex, and the array buffer pointer all get copied on assignment. This is ripe for bugs, as we have seen above.
- Lack of true immutable types.
Update (2014-06-21): Apple will be changing the array semantics.
In my opinion it was due to one single idea: Interactivity. Think about it: These days we revel in the idea of hot-loading assets, changing shaders on the fly, and interacting via scripting languages such as Lua and advanced level editors. What if your whole engine was interactive. Not just parts of it, but all of it
Andy’s system was not just a compiler. It was also a linker, a debugger, a dependency manager and a macro expander, but more importantly -- it was a server. This is so fundamentally important. If you are going to change code on the fly, something needs to know “everything”, and the compiler knew everything. It was live, so you could get access to everything, results of macros, memory on the target.
The results are impressive: the consumer-grade SSDs tested all made it to at least 700TB of writes before failing. Three of the drives have written 1PB (that’s a thousand terabytes, by TechReport’s decimal reckoning, not 1024TB). That’s a hell of a lot more writes than the manufacturers’ stated drive lifetimes, and that’s good news for SSD-buying consumers.
If you haven’t been following along with our endurance experiment, this introductory article is a good starting point. It spends far more time detailing our test methods and system configurations than the brief primer we’ll provide here.
The premise is straightforward. Flash memory has limited endurance, so we’re writing data to a stack of SSDs to see how much they can take. We’re checking health and performance at regular intervals, and we’re not going to stop until all the drives are dead.
Looking back, Android’s existence has been a blur. It’s now a historically big operating system. Almost a billion total devices have been sold, and 1.5 million devices are activated per day—but how did Google get here? With this level of scale and success, you would think there would be tons of coverage of Android’s rise from zero to hero. However, there just isn’t. Android wasn’t very popular in the early days, and until Android 4.0, screenshots could only be taken with the developer kit. These two factors mean you aren’t going to find a lot of images or information out there about the early versions of Android.
The problem now with the lack of early coverage is that early versions of Android are dying. While something like Windows 1.0 will be around forever—just grab an old computer and install it—Android could be considered the first cloud-based operating system. Many features are heavily reliant on Google’s servers to function. With fewer and fewer people using old versions of Android, those servers are being shut down. And when a cloud-reliant app has its server support shut off, it will never work again—the app crashes and displays a blank screen, or it just refuses to start.
Gone is the dynamic nature of ObjC; it has instead been replaced by a rigid, generic based type system. I know the world of C++, Java, and C# programmers have rejoiced. Myself, having worked in Visual Studio building tools for .NET and Windows developers for many years and leaving that for the world of Cocoa and ObjC, I am greatly saddened by this turn of events.
I do not think we got “ObjC without the C”, rather, we got something much more like C# that compiles on clang and bridges into Cocoa a bit haphazardly.
Yes, generics can be useful in particular cases. However, they are not helpful, ironically, in the generic use case. I would argue that simply sticking with a stronger-type base instead of fully type-safe and generic based language would have been a more pragmatic route to take.
I have to wonder, what is the pragmatic goal of Swift? From where I sit, it gets all of the defaults wrong because the defaults should have been about the interaction with the Cocoa API. Until there are native Swift versions of those, all of code looks and feels much messier and far less elegant than what we have today.
I realize that it’s a vain hope that this bug report will be anything than summarily dismissed, but I feel I have to make the attempt nonetheless.
My conclusion is that dynamic dispatch must be a first class citizen in order to make Swift suitable for UI programming. Also, the generics must be much simplified and permissive in order to not obstruct and complicate the day-to-day programming work.
Update (2014-06-22): David Owens II has a further update on the JSON example.
A Bitcoin mining pool, called GHash and operated by an anonymous entity called CEX.io, just reached 51% of total network mining power today. Bitcoin is no longer decentralized. GHash can control Bitcoin transactions.
GHash is in a position to exercise complete control over which transactions appear on the blockchain and which miners reap mining rewards. They could keep 100% of the mining profits to themselves if they so chose. Bitcoin is currently an expensive distributed database under the control of a single entity, albeit one whose maintenance requires constantly burning energy -- worst of all worlds.
Hereʼs why iOS 8 is a big deal. As an example, consider one of my favorite iOS apps, 1Password. Assume you want to sign in to a web site in Mobile Safari and your login credentials are stored in 1Password. This is a very common task that I perform several times a week. Think about the steps you have to go through today on iOS 7 to accomplish this[…]
While iOS extensions are similarly considered components of a containing application (they are bundled together and cannot be deployed separately), their execution model is different than Android. iOS launches extension components into a separate (i.e. third) process from both the containing application and the calling application making the request (called the “host” by Apple).
Alongside an Intent’s destination definition (via an implicit action, explicit class name, etc.), the filter scope can further narrow by referencing a custom data type that is only known to a private suite of applications. Currently in iOS,
NSExtensionItemdata returned from the extension can provide unique type identifiers, but the same is not true for data passed forward to an extension; identifiers are inferred from the type of data passed in (rdar://17217209).
This is important because iOS, via the
NSExtensionActivationRulein the Info.plist, determines when and where to show a custom action extension by comparing the input items passed to the
NSPredicate. By limiting the scope of input items to standard data types, it becomes difficult to create more targeted actions that only respond to special data.
The issue, as Adam Liptak explained in the New York Times, is that original statements by the Justices about everything from EPA policy to American Jewish communities, are disappearing from decisions — and being replaced by new language that says something entirely different. As you can imagine, this is a problem for lawyers, scholars, journalists and everyone else who relies on Supreme Court opinions.
Until now, the only way to detect when a decision has been altered is a pain-staking comparison of earlier and later copies — provided, of course, that someone knew a decision had been changed in the first place. Thanks to a simple Twitter tool, the process may become much easier.
iOS applications have been freed from the rigid silos, the walls that have prevented them from talking to each other. Apple developers can now write extensions to their apps and avail themselves of the interprocess facilities that they expect from a 21st century OS.
Users of the word processor will be able to see and incorporate all files, regardless of how they were created or where they’re stored (within the obvious physical limits). This is a welcome change from today’s frustratingly constricted situation.
To better understand the importance of these technological changes in iOS 8 and the inherent complexity that they’ll add for developers and users, I want to take a step back and contextualize how iOS currently handles file storage and management.
For the past seven releases of Visual Studio (2002, 2003, 2005, 2008, 2010, 2012, and 2013), the Visual C++ libraries have been versioned and each versioned set of libraries is independent of other versioned sets of libraries. For example, a C++ program built with Visual C++ 2010 using the DLL runtime libraries will depend on msvcr100.dll and msvcp100.dll, while a C++ program built with Visual C++ 2013 will depend on msvcr120.dll and msvcp120.dll.
Starting with Visual Studio “14,” we will stop releasing new versions of the CRT with each release of Visual Studio. Whereas before we would have released msvcr140.dll in this forthcoming release, then msvcr150.dll in the next release, we will instead release one new CRT in Visual Studio “14” then update that version in-place in subsequent releases, maintaining backwards compatibility for existing programs.
The “best” example of this maintainability problem could be found in the old implementation of the printf family of functions. The CRT provides 142 different variations of printf, but most of the behavior is the same for all of the functions, so there are a set of common implementation functions that do the bulk of the work. These common implementation functions were all defined in output.c in the CRT sources(1). This 2,696 line file had 223 conditionally compiled regions of code (#ifdef, #else, etc.), over half of which were in a single 1,400 line function. This file was compiled 12 different ways to generate all of the common implementation functions. Even with the large number of tests that we have for these functions, the code was exceedingly brittle and difficult to modify.
Aside from the new indoor positioning site, indicating forthcoming indoor maps, and the improvements in China, Apple’s mapping data still feels like it hasn’t shaken its early reputation. Search still sucks, and my local data is sometimes still a crapshoot. Despite the enormous improvements throughout iOS 8, it’s (I think, understandably) frustrating to go yet another year without hearing about progress in the Maps department.
“There were multiple improvements that didn’t make it into iOS8,” a source tells us.
Two years after parting company with Google, Apple is still trying to work out its killer Maps app.
Apple never reveals its plans ahead of announcing them, but a fairly detailed report published prior to the conference from 9to5Mac laid out what it claimed was Apple’s map news.
Key changes included enhanced, “more reliable” data; more points of interest and better labels to make certain locations like airports, highways and parks easier to find; a cleaner maps interface; and public transit directions — that is, providing people with data about nearby buses, subways and trains. Further ahead, the report noted plans to integrate augmented reality features to give people images of what was nearby.
Why didn’t they appear? One tipster says it was a personnel issue: “Many developers left the company, no map improvements planned for iOS 8 release were finished in time. Mostly it was failure of project managers and engineering project managers, tasks were very badly planned, developers had to switch multiple times from project to project.”
I was not that happy to see App Store bundles announced, as it seemed like a way of driving app prices down even further. Instead of one app for 99 cents, you can get two or three. However, Michel Fortin suggests that bundles could also be used to implement upgrade pricing. Put the old and new versions of your app in the same bundle, and the App Store will discount the bundle based on what you already paid for the old version. You end up getting the new version at a discount.
This new version packs a lot of great new features, including a completely redesigned, themeable user interface, extensibility via custom, script–based actions, suggestions for Google and DuckDuckGo, live Calendar input feedback, new indexing rules like Emoji or Finder Tags, Info Browsing for accessing an item’s metadata and so much more.
LaunchBar has been one of my favorite apps for the entire Mac OS X era.
Update (2014-07-06): There are also some great new features in 6.0.1 and 6.0.2.
In Objective-C that is easy as pie, just call NSClassFromString(aClassName) and then alloc/init the Class it returns. However, now that Swift is destined to become the lingua franca of iOS I decided to investigate how one might implement these reusable components in Swift. Instantiating classes by name turned out to be a stumbling block, as it appears that Swift does not yet support this.
I was able to get an object that represents a class (named AnyClass), but there was no way to get from there to a live instance of that class. So instead, I hopped into the parallel universe of Objective-C to create an object, which then gets returned back to Swift. This is why ObjectFactory can only work with NSObject subclasses; I’m relying on Objective-C to alloc/init a new object, and those methods are defined by NSObject.
I still think one of the less remarked on aspects of Swift is its lack of dynamism. It does not seem like Core Data, Scripting Bridge, or PyObjC could be written in Swift. Swift gives you a smarter compiler, but less flexibility at runtime. Swift is famously advertised as Objective-C without the C. Curt Clifton says:
Starting to fear that Swift is really Obj-C without the Smalltalk[…]
iOS 8 randomises the MAC address while scanning for WiFi networks. Hoping that this becomes an industry standard.
Whenever you walk around a major Western city with your phone’s Wi-Fi turned on, you are broadcasting your location to government agencies, marketing companies and location analytics firms.
In shopping malls, for instance, a firm called Euclid Analytics collects, in its own words, “the presence of the device, its signal strength, its manufacturer (Apple, Samsung, etc.), and a unique identifier known as its Media Access Control (MAC) address.” In London last year, one start-up installed a dozen recycling bins that sniffed MAC addresses from passers-by, effectively tracking people through the area via their phones. Such companies go to great lengths to explain that such information in not personally identifiable—except that repeated studies have shown that this data can indeed be used to infer a great deal about your life.
In adding MAC address randomization during Wi-Fi probing, Apple manages to both eliminate a potential privacy leak and drive companies interested in location-based advertising toward a solution it prefers. iOS users who would prefer to opt out of iBeacon can first ensure they have no iBeacon-aware apps installed (like the official Apple Store app), or they can disable Bluetooth. Until iOS 8 arrives, iOS 7 users who would prefer not to have their MAC addresses tracked in public can disable Wi-Fi when they’re out and about.
The new MAC randomization system is the latest in a line of privacy-focused moves from Apple that have come to light as developers digest the wealth of material offered at last week’s Worldwide Developers Conference.
Most visible among those change is iOS 8’s new “While Using” location privacy option. The new setting allows users to restrict apps from determining their location unless the app is in active use, preventing apps from collecting location data in the background unless explicitly authorized to do so.
I think this is a good idea, but I’m skeptical that it will do as much for privacy as people are saying. Julian Bhardwaj:
Most devices use both passive and active discovery in an attempt to connect to known/preferred networks. So it’s very likely that your smartphone is broadcasting the names (SSIDs) of your favourite networks for anyone to see.
The unfortunate news is there doesn’t appear to be an easy way to disable active wireless scanning on smartphones like Androids and iPhones.
However, you can at least tell your phone to ‘forget’ networks you no longer use to minimise the amount of data leakage.
In other words, with MAC address randomization, the names of your favorite networks become an identifier for you. Secondly, snoopers can use a common network name that your phone will try to auto-connect to, at which point they’ll get your real MAC address.
Ole Zorn quotes the App Store Review team:
If we do not receive an update within forty-eight hours, your app [Pythonista] may be removed from sale.
Apple itself takes it sweet time in responding, but Zorn is told he must neuter his app—highly regarded and in the store for years—within 48 hours or it will be removed from sale. As with Editorial, Apple claims that the app violates rule 2.8:
Apps that install or launch other executable code will be rejected.
All the apps in question are, of course, sandboxed, so this is not about security. And it’s not as if Pythonista is trying to be an app store within an app. It’s just a productivity app, in fact one of the primary examples of how iOS can be used for more than just content consumption. Federico Viticci (in 2012):
We’re in the early stages of iOS automation, but Pythonista, Launch Center Pro, and x-callback-url are indicating the path other developers should follow.
Pythonista shows that it’s possible to be a power user on iOS while playing by Apple’s rules.
Gabe Weatherhead writes to Tim Cook:
[Editorial and Pythonista are] the first apps I tout as examples of the vibrance of iOS and, I dare say, I love them.
Update (2014-06-13): Ole Zorn:
Just submitted Pythonista 1.5 within Apple’s 48h deadline. “Open in” menu integration is gone, I hope this is enough.
If Pythonista is drummed out of the App Store, then iOS is useless to me as a platform.
As much as Apple is “opening up” and extending the functionality available to third-party developers, this kind of rein-tightening is a huge drawback for iOS developers, for two big reasons.
Update (2014-06-16): Ole Zorn:
So what was the problem Apple had with the previous version? Turns out, they didn’t like the Open in… menu integration I had added in 1.4 because that would allow you to import executable code from external sources. My theory is that this policy is in place to prevent apps that circumvent the App Store, e.g. by offering downloadable games that don’t go through Apple’s review (and revenue chain via in-app purchases).
I’m sad to see this feature go. It wasn’t just a convenient way to import scripts, it also enabled some pretty interesting automation workflows that could process the contents of pretty much any kind of file you could access on your iOS device.
My friend Matt Golec’s Penny Press board game won Cards Against Humanity’s Tabletop Deathmatch competition. You can view the pitch video and the finale on YouTube. There’s now a Kickstarter to get the game printed:
We’re really excited that Penny Press is going to be a reality. We’re here on Kickstarter with a very low goal because our prize money will let us print a small run of the game. With your support, we can upgrade the components and print more games! We’d like to bring Penny Press to lots of tabletops. It’s a pretty great game.
In Penny Press, you run a newspaper in the turn of the century Yellow Journalism era. Various stories from different newsbeats will be added to the board, and you’ll be able to place your reporters on them. On each turn, you’ll be able to take one action with your reporters(placing or moving them onto stories) or go to press, if you think you’re ready! Going to press involves laying out the story pieces on your player board, to form the front page of your paper! But you’ll only be able to print stories that you’ve got a majority of reporters on. Better front pages with desirable stories will score more points, and increase your circulation.
Update (2014-06-11): Justin Berman reviews Penny Press.
Apple rejects Editorial update for a feature that’s been there since August 2013 with version 1.0? Come on, guys.
I mean, I’m pretty sure Apple knows about this app.
Ole Zorn shows the response from App Review:
It would be appropriate to remove this feature from your app or to re-evaluate the concept of your app.
Apps that download code in any way or form will be rejected.
So before you get too pleased with how different WWDC 2014 was, remember that Apple is still at war with computer science. Hopefully, they won’t figure out that my notes for WWDC, which include some lines of code, are downloaded from a .txt data file on Dropbox…
Update (2014-06-09): Daniel Jalkut started a conversation about this on Twitter.
Update (2014-06-11): Edge Cases (starting at 41:45) discusses the positive changes at WWDC as being personality driven and a response to competitive threats, rather than a shift in Apple’s beliefs.
Update (2014-06-16): Jesper:
But so much for wanting a theoretical open platform. Apple announced and demonstrated that it’s ready to treat developers better, and it followed it up by announcing and demonstrating that this quest is incompatible by their current methods by rejecting apps that they already have for features that they didn’t just add for breaking rules that they’re not breaking.
Apple has added a handy feature into OS X to easily capture the screen of an iPad or iPhone on the Mac itself. Apple positions the feature as a way to help developers quickly make app previews, which Apple introduced as part of iOS 8’s improvements to the App Store, but there is no reason why this couldn’t be used by others for different purposes.
In testing, the recording is currently extremely laggy. It is reasonable to expect video quality will improve significantly as iOS 8 and OS X Yosemite approach public release.
When I visited it for the FIRST time, I got this lovely HTTP interaction. That’s SEVEN HTTP 301s, count them, 7, before I get to the destination page.
It would have been 8 redirects if I’d counted t.co as well. Note also that after it bounced around three of Slate’s URL shorteners, it also goes through goog.gl as well.
Every redirect is a one more point of failure, one more domain that can rot, one more server that can go down, one more layer between me and the content.
Overall, the program looks great, with developers being allowed to invite up to 1,000 beta testers per app and testing privileges being bound to usersʼ Apple IDs instead of specific iOS devices.
So it seems that your beta app has to go through review at least once, but thereafter Apple may allow you to skip the review unless you make significant changes (whatever that means).
Upon hearing Apple’s Metal announcement, perhaps the greatest surprise was that iOS developers were in a position where they needed and could benefit from a low-level API like Metal. In the PC space we’ve been seeing low-level APIs rolled out as a solution to the widening gap between CPU and GPU performance, however the SoC class processors in Apple’s iOS devices are a very different beast. As one would expect for a mobile product, neither the CPU nor the GPU is high performance by PC standards, so why should a low-level API be necessary.
The answer to that is that while SoCs are lower performance devices, the same phenomena that has driven low-level APIs on the PC has driven them on mobile devices, just on a smaller scale. GPU performance is outgrowing CPU performance on the SoC level just as it has been the PC level, and even worse, SoC class CPUs are so slow that even small amounts of driver overhead can have a big impact. While we take 4000 draw calls for granted on desktop hardware – overhead and all – it’s something of a sobering reminder that this isn’t possible on even a relatively powerful SoC like the A7 with OpenGL ES, and that it took Metal for Crytek to get that many draw calls in motion, never mind other CPU savings such as precompiled shaders.
Update (2014-06-13): RenderingPipeline:
We can see, that a lot of complexity is hidden from the programmer and that a lot of tricks (probably way more than I have mentioned here) have to be performed to hide what is actually going on. Some of those tricks make the life of the developer simpler, others force him/her to find ways to trick the driver (e.g. the mentioned “useless” draw calls to force the driver to cache states early on) or to learn the possible side effects of API calls (for example which can stall the GPU and how to force a stall to reduce latency).
Some graphics APIs now try to remove most of these tricks by exposing more of the actual complexity – in some cases by leaving it to the program so solve the resulting problems. It’s been said that the graphics API of the PS3 went in this direction (as I’m not a PS3 developer I don’t get access to the documents to check and even if I would be one, the NDA prohibits all devs from describing any details), Mantle is going in this direction (we will see more about how it’s done by AMD when the documents get released), as will Microsoft with DirectX 12 and now Apple is doing the same with Metal.
Each draw costs some time on the CPU and some time on the GPU. The Metal API reduces the time spend on the CPU by making state handling simpler and thus reducing error checks by the driver if the state combination is valid. Precomputing states also helps: not only can the error check be done at state build time, the state change itself requires fewer API calls. Being able to build command buffers in parallel also increases the number of possible draw calls if the application is CPU bound.
The rendering on the GPU on the other hand is not faster, an application that only makes a few calls to draw very huge meshes will not benefit.
Update (2014-06-14): Guy English:
The issue with OpenGL is that an incredibly complicated state machine is being addressed in an atomic fashion on a per function basis. By that I mean that each call into OpenGL required a check to make sure the state was valid for the device. OpenGL error reporting is such that no functions return an error code. Instead they set a GL local variable that’s accessed though the glError() function. The lack of immediate error returns, as well as other features of the API, derive from its earlier days where it was envisioned as a largely asynchronous affair. Commands would be buffered and fired off to the renderer and there would be only occasional synchronization points.
While that’s a laudable abstraction, that’s not what we’ve ended up with in the real world. Our ability to render 3D graphics is coming closer to the CPU rather than further. Intel has been shipping respectable (yes, gamers, I know) parts for a couple of years that perform well. Meanwhile, Apple’s A7 has a tremendous amount of capabilities that haven’t, and can’t, be unlocked via the OpenGL API. Integrated memory and graphics processing are not what OpenGL was designed for.
Metal turns that that upside down. Rather than making discrete state changes (flipping switches) directly in the driver Metal allows you to order up a set of state that’d you want applied. If it can’t be done you’ll know. If it can then that set of state is good and can be applied, without further checking, to other rendering operations and contexts. Metal turns a set of many tiny decisions into an opportunity to green light a plan.
Hybrid apps are never going to compete with native on performance, but as hybrid performance improves, the hybrid development approach becomes good enough for an increasing number of apps. With the performance improvements that iOS 8 offers, and performance increases on other platforms — such as Android 4.4 switching to a Chromium-based web view — things are looking up for hybrid development.
The possibility to enrich the functionality of apps and customize the operating system will come with new guidelines and rules developers will have to follow. For one, extensions will always come embedded inside apps users download from the App Store: an extension will be bundled with an app, and developers won’t be able to release standalone extensions on the App Store or submit apps that only contain extensions.
The even bigger reveal from Federighi’s presentation were Actions, app extensions that will allow users to view or manipulate content inside another app. Federighi used two examples to show the “view” and “non-view” nature of extensions: a Bing translate action, which used a feature from the Bing app to translate Japanese text in Safari without showing any additional interface; and a Pinterest web clipper, which presented a custom-designed clipping tool to save an image from a Safari webpage into the Pinterest app without actually launching the app.
More importantly, Actions will nurture the creation of rich workflows that aren’t possible with URL schemes. In a demo shared with developers at WWDC, Apple showed an image annotation tool capable of editing an image from a Safari webpage and insert it back into the webpage when done. It was reminiscent of Markup, a feature of OS X Yosemite that also happens to work as an Action extension. This kind of visual, interactive inter-app communication will result in user-friendly and powerful workflows that will be akin to "mini apps" available right inside a host app without having to switch contexts or be limited by bookmarklets.
Finder Sync will allow apps that sync a local folder with the web to modify the Finder interface with badge icons and custom menus. The latter seems primarily aimed at services like Dropbox, which had to reverse-engineer the Finder to put sync icons and logos on top of folders.
Zorn, who modified the default iOS keyboard with extra rows and buttons in his apps, says he is “thrilled” that Apple is enabling custom keyboards on iOS, but also “a bit disappointed by some of the restrictions”. For example, Apple’s won’t allow keyboards to have any kind of selection controls, so tweaks such as the popular Hooper Selection concept won’t be allowed on the App Store.
Apple revealed a sneak peek into Mac OS X Yosemite earlier this week. Not surprisingly, Apple updated its desktop OS to match iOS 7’s design language. The new OS X now embodies a brighter and flatter styling, coupled with icon updates, font changes, and translucent materials. Here’s a quick look at the visual design changes in Yosemite and my impressions of them.
I generally like the new application icons (except for System Preferences) and Dock. I’m not fond of the bright blue folders, the thin and hollow toolbar buttons, the translucent and sidebars and title bars, or the readability of Helvetica Neue.
Update (2014-06-18): There’s a new (and better) System Preferences icon in DP 2.
Update (2014-08-01): Paul Kafasis:
The simplification generally works well. These new icons are still recognizable as representations of real-world objects, without unnecessary embellishments or detail. However, Safari’s new icon is somewhat problematic.
I am not a lawyer, but if I am reading this correctly, it means that beta version of the operating systems and SDKs are still under NDA, but Apple allows developers to discuss new APIs and features that have been introduced at WWDC in public. That should cover pretty much all the new stuff in iOS 8, Yosemite and the Developer Tools.
The interim scenario we’ve been living in since then — no talking about the unreleased version, even though we all have it on our laptops — is still frustrating and fairly absurd. I wonder if either Apple’s going to give us an official clarification, or people are going to just go ahead and start talking. It would be nice for the conversation to be led by the top developers, speakers, and instructors instead of the rumor-mongers, for a change.
Soon after releasing version 1.0, Michel Fortin has announced a new version of Counterparts Lite that adds support for XLIFF files, as well as license leases so that developers can provide licenses to translators. I’ve been testing it for a week or so, and it’s a great app.
On Thursday, the OpenSSL Foundation published an advisory warning to users to update their SSL yet again, this time to fix a previously unknown but more than decade-old bug in the software that allows any network eavesdropper to strip away its encryption. The non-profit foundation, whose encryption is used by the majority of the Web’s SSL servers, issued a patch and advised sites that use its software to upgrade immediately.
The biggest reason why the bug hasn’t been found for over 16 years is that code reviews were insufficient, especially from experts who had experiences with TLS/SSL implementation. If the reviewers had enough experiences, they should have been verified OpenSSL code in the same way they do their own code. They could have detected the problem.
Fuzzing may have worked. However, as the history (see below) shows, knowledge of TLS/SSL implementation seems vital.
Our idea is to go further than traditional filesystems and databases by supporting document organization, structured documents, version control, rich undo/redo, and collaborative editing in a single framework. CoreObject allows apps to easily adopt all these features and create a coherent user experience, without each app reinventing the wheel in incomplete or incompatible ways.
- Apple’s Swift Site
- The Swift Programming Language (iBooks, highly recommended)
- The Swift Programming Language (Web)
- Using Swift with Cocoa and Objective-C (iBooks)
- Using Swift with Cocoa and Objective-C (PDF)
- WWDC 2014 Keynote Video
- Stack Overflow
- Apple Developer Forums
- Chris Lattner’s Home Page
- Typeclass Encoding in Swift
- Graydon Hoare
- Keith Gugliotto on Swift’s speed
- Matt Brewer
- Ray Wenderlich’s Swift Cheat Sheet
- Learning Swift: Ordered Dictionaries
- Combining ObjC and Swift in One Project
- Mark Bernstein
- Lambda the Ultimate
I’m really excited about Swift. It’s along the lines of what I had hoped Apple was working on in secret. Having better support for types is great, although I’m slightly concerned that Swift is not dynamic enough.
- Immutable Arrays With Mutable Values
- How Do I Declare a Closure in Swift?
- Terrible Swift Ideas
- Swift Initializers
- Swift Native Base Class or NSObject
- Michel Fortin
- Remove Features for Greater Power, aka: Swift and Objective-C Initializers
- Unit Testing in Swift
- Claim Chowder Special Edition: xlang
- Clark Goble
- Swift Will Be Open Source
- Swift Language Mailing List
- BBEdit Codeless Language Module for Swift
- Swift Implementation of OFTrie
- Swift Array Assignment
- Evan Swick
- Evan Miller
- GCD in Swift
- iOS Developers Need to Know Objective-C
- Expression Interpretation Problem with Swift Closures
- Swift and Scripting Bridge
- Instantiating Classes by Name in Swift
- Experimenting With Type-safe Unit Calculations in Swift
- How to Make Awesome UI Components in iOS 8 Using Swift and XCode 6
- Regex in Swift
- Is This Really ObjC Without the C?
- Swift Standard Library Documented
- A Swift Reaction
- Swift: Not Quite There, But Too Far Gone Too
- Swift Arrays
Update (2014-07-02): Carlos M. Icaza has made the Swift books available in PDF format.