Historically, Apple’s SDKs only contain the bare minimum of components, and those APIs push you towards Massive View Controller. By tracking down the responsibilities of your view controllers, separating the abstractions out, and creating true single-responsibility objects, we can begin to reign those gnarly classes in and make them managable again.
Nat!:
The project started out on iOS 5, which was quickly succeeded by iOS 6. I would have been extremely surprised at the beginning, if someone had told me, that at the time of iOS 8s release our app still wouldn’t be done yet. But here is a recollection of all my faults: why it took way too long.
[…]
I bought AppCode solely to run “Inspect Code…”. The results returned are quite a bit more helpful than what Xcode Analyzer returns.
[…]
I probably wrote a hundred little apps, that tested out some feature, or started coding a subview with it. When the code was complete I moved it into the main app, deleted the original files and then symlinked the files from the main app in the test app. This way, I could go back to the test app to tweak something, when it didn’t work out in the main app. Needless to say being able to focus on just a small piece of code in a controlled environment is much more convenient.
[…]
This unfortunately means, that I am almost invariably are going to hit a brick wall at some point in time. For example, I spent way, way more time dicking around with UIScrollView than I eventually needed to code my own custom UIScrollView. The opacity of the iOS libraries means, that I always have to guess, how it’s really implemented, guess how it could break in the next iOS version and also guess beforehand, if everything is exposed like I will eventually need it.
[…]
Subclassing CoreData classes or overriding CoreData accessors is a path to misery, where I am unfortunately still traveling on. I am not 100% sure, but I would probably have been better off, either just going sqlite-direct or to use a stripped down MulleEOF for Dienstag.
[…]
It was interesting, because “naive code” only suffered a factor 2 ARC penalty, whereas “clever code” suffered a factor 10 ARC penalty. So ARC seems to be a great programmer equalizer in that respect. I didn’t investigate other “patterns”, but I also continued not using ARC. Less magic, less pain.
Many had expected Swift to be more an Objective-C 3.0 than it turned out to be. But what could we have expected such a hypothetical language to look like?
This list is actually just a sample to get the ideas flowing, and to illustrate how some of the hurdles with ObjC 2.0 can be overcome by a successor that breaks syntax with the past, but still retains full backward compatibility.
I think the biggest disservice we can do to the Cocoa developer community is remove the underpinnings of the ObjC runtime. It is the language’s, and I truly believe, the platforms’ greatest strength.
I believe if we hide the complexities of C from our source code and focus on letting the power of the ObjC runtime shine through in our code, we can create a new language that provides of the great flexibility of the ObjC runtime while still accomplishing many of the goals that Swift is attempting to solve - namely safer code by default.
Consider how much progress could have been made with Objective-C had the resources from the Swift project been applied to it instead. Swift is an immensely complicated language that still needs a long time to mature. Objective-C is a much smaller language with a solid core and seemingly a lot of low-hanging fruit (syntax improvements, increased safety).
For example, a better blocks syntax and support for Python-style comprehensions in Objective-C would do a lot for me today, making my code more concise and readable. Swift’s generics feature was likely more difficult to implement, and it arguably makes the code less readable and for dubious benefits.
Additionally, an improved Objective-C could in many cases compile down to binaries that work smoothly with existing code and older OS versions. It could still use the same runtime. With Swift, Apple is instead dropping some of the benefits of the Objective-C runtime and creating migration issues because some Swift elements don’t interoperate with Objective-C, and others bridge but with performance penalties. We’ve only seen the tip of the interoperability iceberg because so far all of Apple’s APIs are native Objective-C.
Apple seems to be betting that the benefits for making a whole new language will be worth the migration costs and the stagnation of the language that most of us are actually using. I’m not convinced because most of my favorite Swift features seem like they could have fit into an Objective-C 3.0.
For one of my projects I’m working with NSVisualEffectView and behind-window blending.
[…]
There may be other gotchas, of course, but these are what I’ve found so far.
I assumed iOS 8 would offer a good experience on the iPad Air, but after playing with it as well as the iPad mini with Retina display, it’s clear that iOS 8 on iPads is clearly far from ready. Although there are loads of bugs and performance issues that currently exist on iOS 8, this post is not for those. Instead, let’s talk about some of the interface issues, design oddities that are seen on iOS 8 and how the iPad’s potential is being wasted by not taking advantage of the larger canvas.
For the past few years, based on what I’ve written in this blog and elsewhere, blind enthusiasts of the Android platform have labeled me as an Apple fanboy. It is true that I use Apple devices and that I applaud Apple for its outstanding out-of-the-box accessibility in iOS/7 and the pretty good version of the same on OS X.
[…]
So, it remains that iOS/7 is the all time out-of-the-box accessibility champion. As iOS/7 can no longer be purchased from Apple, this also means that the most accessible solution for mobile computing is now a thing of the past. We’ve regressed in iOS/8 and Apple must be taken to task for such.
[…]
Apple is doing something different and dangerous with their accessibility strategy. By choosing to release iOS/8 with so many glaringly obvious bugs, they have allowed accessibility regressions to vastly overshadow any improvements in such in iOS/8. My personal conclusion is that this is the result of a failure by the Apple competitors, most notably Google and Microsoft, to actually compete in this space. Apple released iOS/7 with a 100% accessibility API compatibility rating, the only out-of-the-box solution that has even tried to achieve such. Apple is still the clear leader in accessibility in the mobile computing arena but has proven that they can disappoint as well as surprise this community with their accessibility efforts.
Detailed in this post are possible accessibility bugs which members of the AppleVis Editorial Team have identified during their testing of iOS 8. If you have not already updated your iDevice to iOS 8, we strongly recommend that you read through this post and any comments before doing so, as we believe that there are a number of bugs in this release which might have a significant impact on the user experience for some blind and low vision users.
Update (2014-10-20): AppleVis:
Based upon what we have typically come to expect from a full point release of iOS, it is likely that some will be disappointed to see that this update does not include more fixes for the accessibility-related bugs that were introduced in iOS 8.0. However, it is worth noting that iOS 8.1 comes just a month after iOS 8.0, and that Apple appears to be working on a very different version schedule to what we have typically seen in the past.
[…]
Here are the fixes and improvements that we have found in our initial testing of iOS 8.1.
James Dempsey and the Breakpoints (iTunes):
Backtrace steps through fourteen years of Mac and iOS development tunes, taking you on a musical journey into the biggest album release in iOS and Mac programming history.
From the driving beat of Goto Fail to the memory management oldie Hold Me, Use Me, Release Me every song is here. From crowd favorites to deep cuts, each track melds music with humor-filled tech lyrics, welcoming you to a sonic wonderland of geektastic amusement.
Update (2014-11-24): Dempsey is posting the lyrics.
