Great insight from Tom Harrington on developing iOS 8 app extensions. For developers, Extensions are still very much uncharted territory and Tom breaks down some of the gotchas you'll come across when in Xcode.
I've been using this Apple Wireless Keyboard since July 2011, when my current iMac arrived. A few days ago, the '1' key wasn't registering clicd every few strokes. It got worse until, eventually, I couldn't use the '1' key at all. The next day, the '2' key started to go.
Google searches turned up a whole host of creative things to try to get the keys to work again, everything from repairing the keyboard to shaking the keyboard violently. I tried them all, nothing worked.
For most people, this isn't as big of an issue as, say, the space bar not working. But for a Cocoa developers, it's a big deal. It's not the '1' and '2' characters I need the most to get work done, it's the '!' and '@'. The '@' is for literals like declaring strings and arrays (no way in hell I'm going back to the old way of formally declaring an NSString and NSArray every time I need one created). The '!' is for Swift development because Chris Lattner.
Luckily, I had a backup AWK. Good thing, because the closest Apple Store, according to the Store's app is 248km away.
Technology, no matter how well built or what logo is on the back, will eventually break. If only it had happened 3 weeks ago, it would be covered under my (now expired) iMac's AppleCare.
Do you have any ideas I could try? Let me know.
In the latest version of Bug Trackr, I removed the hamburger menu and replaced it with a standard UITabBar. It was a tough decision, especially considering the amount of time I spent crafting the old interface that Bug Trackr 1.0 shipped with. I deleted weeks of work and abandoned a UI that worked best for me.
This year at WWDC, Apple made it pretty clear that they don't want developers using a hamburger menu in iOS. In fact, they frown upon it. Apple argues that it makes for a bad user experience and in most cases users tend not to open the side bar menu at all. Instead of freeing up screen real-estate, developers were urged to adopt a more traditional Tab Bar or List View.
Even though Bug Trackr was an app I had originally made for myself, it is now being used by thousands of developers around the world. Because of that, I have an obligation to put their preferences ahead of my own. After all, that's the business I'm in.
Why didn't I use a standard tab bar in the first place? Bug Trackr started as an iOS 6-based project and I never liked the way UITabBar looked or felt pre-iOS 7. It was clunky, tired, and required more customization to get to a level I was happy with than I was prepared to do.
iOS 7 made some nice and overdue changes to UITabBar's appearance but I had already implemented the hamburger menu and stuck with it. Chalk it up to building code-debt I suppose.
So in June, after hearing about the usability shortfalls of the hamburger menu at WWDC14, I went to work restructuring the navigation UI. At the same time, I made some big improvements with text layout, adding support for Dynamic Type to more parts of the app, and tuning cells and the like for clarity.
I'm proud of the Bug Trackr 1.2 update and I know users will love the changes (unless you're a holdout for burgers).
I have an iOS 8 update in the works. Awesome stuff like Entensions and sync are in the works, more on that next month.
Ps. New apps and significant app updates that are built against iOS 8 will require iOS 8. I will continue to support iOS 8 until iOS 9 ships and so on.
One item on my iOS 8 wish list from May was a new UIKit API for empty content views in UITableView. A simple UITableView data source method where you can return a UIView. UITableView would then intelligently display the provided UIView whenever there was no content in the tableView.
But WWDC passed and no such luck. Luckily, DZNEmptyDataSet to the rescue! You can find it here on Github.
It's easy to add to any project using UITableView or UICollectionView and it's being updated regularly.
So this... ...Becomes this!
I've tried many other open source projects and rolled a few techniques myself but none came as close as DZNEmptyDataSet.
Why use an empty content view? Primarily for communicating to the user why the screen is empty and how to add content. It's highly unintuitive, especially on first launch, to display blank rows (as seen in the first image). While a good UI design is self-explanatory and helpful, the default implementation is not.
In the example on the right (taken from Bug Trackr 1.2), I tell the user there isn't any content saved, what they can expect this view to contain, and how to add content. In this case, even though I have an add button at the top right of the screen, I include an "Add Bug" button in the empty content view. Both buttons trigger the same action. This makes it crystal clear that to get new content, you have to tap the add button.
It may seem obvious but, for users launching an app for the very first time, an empty tableView is jarring and confusing.
Apple's default implementation in UITableView is far from ideal and it's interesting that for most of Apple's own apps they implement an empty content view (private API). Until Apple makes their empty content view API public, DZNEmptyDataSet is here to fill the gap.
WWDC 2014 was different than past years. As usual, Apple surprised and delighted both consumers and developers alike. But this year, the biggest surprise wasn't a software or hardware announcement. It wasn't Yosemite's UI redesign, new APIs, Extensibility, iCloud Drive, or any of the other fantastic improvements developers have been yearning for.
The surprise, this year, was in the sum of these announcements. Apple biggest gift was in how they made developers feel.
Apple has always been, or at least seemed, to hold developers at arms length. Developers have felt like second-class citizens on Apple's platforms, often not being granted access to APIs that Apple has kept secret. It's resulted in Apple's apps being 'better' than what was capable using public APIs. No more - Apple made it clear this year that with iOS 8 and 10.10 that we, Apple and developers, are on the same playing field. We have access to the same tools and share the greatest number of APIs than ever before. Fantastic news!
This is one example of a change of tone and a perceived embracing, on Apple's part, of developers. There's a greater sense of respect this year in contrast to years past.
WWDC14 also brings many developer features that we all have been asking for but most had given up hope on receiving. Features like a (finally!) redesigned and improved iTunes Connect, allowing up to 1000 beta testers, and new services like the Testflight beta testing service.
This year Apple laid out, in plain English, that not only are they listening, but they value us as developers for their platform.
They didn't have to do any of these things for us. They're perfectly in their right to leave things the way they are. But it looks like they now want to. That's major.
Going into the keynote, developers expected more of the status quo. They came out in disbelief.
They had just witnessed a new Apple.
This new Apple is confident not only about this week's announcements but what's in the pipeline. That's a great sign.
This week, Tim Cook and co. showed us that they've turned a new page. The most important message they sent to customers wasn't about the great features iOS 8 and 10.10 will bring. Apple's message was the greatest feature of Apple's ecosystem is its 3rd party developers.
Apple surprised and delighted and developers left WWDC feeling better about the platform and their jobs than when they arrived. I'd say that alone makes the conference a success.
I hadn't heard much about Jimmy Iovine until news broke of the Apple/Beats deal. If you haven't seen the interview Iovine and Eddy Cue did with Recode the day of the acquisition announcement, watch it here.
My first takeaway was how seemingly open Jimmy was. And, in typical fashion, how guarded and scripted Cue came across. Cue seemed downright uncomfortable talking to Mossberg and Swisher. Iovine seemed in the element. Seemed to love the spotlight.
Jimmy seemed skilled at directing the conversation, laying out the points he wanted to make, and answering questions he didn't like without really giving the answer.
When Cue was asked similar questions, he seemed to stumble while trying to come up with an Apple-approved response. Cue seems to be comfortable sticking to the script. And that's totally fine. But it doesn't make for a good interview, it makes for a better news release.
If you'll notice in the video, there were quite a few moments of laughter from Jimmy's quick responses to Walt and Kara. As Marco Arment put it, Iovine has charisma.
After Jobs' death, nearly 3 years ago, it become clear Apple's events and appearances had been lacking a certain... je ne sais quoi.
Tim's performance has been impressive as iCEO. In public and behind the scenes, in my opinion, he's excelled. On stage though, he comes across as vanilla, scripted, and bored. That's not to say he does a bad job. In fact, he pulls off stage appearances without a hitch. And maybe that's the problem.
We all waited for a technical difficulty while Steve was giving a Keynote. It was where he really shined. He would make a few jokes, we all had a good laugh, and moved on. No big deal.
When I watched Cue during the Recode interview, I couldn't help but thinking that a question he wasn't expecting would derail him. Seeing his discomfort made my uncomfortable.
Steve performed, Cue presents.
Jimmy Iovine shares Jobs' charisma. Jimmy seemed comfortable on stage at Recode. More than that, he seemed to be having fun.
Charismtic and fun are two elements Apple has been missing. With Iovine it seems to have found it in abundance.
With WWDC and the public unveiling of iOS 8 under a week away, I've created my wish list for the new operating system. These are things I could realistically see happening, not pie in the sky idea. We'll save those for another day.
Search in Settings.app. The Settings app in iOS has become so bloated, it's hard for users to find what they're looking for. A simple search field will save users a lot of time and frustration when they know what they're looking for.
Airdrop between iOS and OS X. Currently I cannot share a photo from my iPhone to my Mac using Airdrop. File this one under low-hanging fruit.
Retire Newsstand. The usefulness of Newsstand in iOS has come and gone. Apps relegated to Newsstand are often forgotten about and it's time to treat a Newsstand app like all others instead of keeping them in purgatory.
Retire GameCenter.app. As with Newsstand, Game Center is seldomly used and mostly forgotten about. Move the Game Center functionality from the dedicated app to the apps that use the service.
Bring back the Facebook and Twitter post buttons in Notification Center from iOS 6 and move them to Control Center. Easy posting access from anywhere in iOS was convenient and a feature I really miss in iOS 7.
Fix that god awful iOS 7 shift key. Is it off, on? Who the hell knows?
3rd-party support for Touch ID. A new system where developers wouldn't have low-level access to the Touch ID system. Instead, the system would authenticate the user and grant the app access to user data.
Beta App Store. Allow Developers to distributed beta versions of apps to a curated list of testers with the App Store as the back-end.
Support in UITableView for placeholder views. Currently, when a table view in iOS has no data, the default is to show empty cells. To show a placeholder view dynamically when there's no data is a lot of work to implement for developers.
A better way to port iOS apps to the Mac. The current way is bogged down by bloated frameworks and the fact that NSView isn't layer backed (right?). Here's looking at you, AppKit.
Some days feel exactly like this.
From one of the best articles I've read all year. If you're interested to know what is it exactly that I do all day, have a read. Honest, insightful, and pretty funny too.
For the last 3 weeks, the Mac App Store has been showing me repeated pending updates for the same version of apps after they've been installed.
Take the above photo for instance. The Mac App Store is telling me that I have to update iAd Producer because version 4.2 is available. The problem is, I've already installed this update through the Updates page in the MAS app. In fact, I've installed this update twice. Even after the second time, it's telling me to install it again. I can open the app and verify version 4.2 is installed.
The first update was a delta update, the second time it was the full app. In this case, 42MB and 312MB respectively. The issue appears in 10.9.2 and 10.9.3.
This isn't the first time I've noticed this problem. It appeared in the weeks leading up to WWDC 2013 and on iOS 6 before the public launch of iOS 7 last September. Is there something going on behind the scenes with Apple's servers before an Apple software event? That's my best guess.
I would file a bug report like I did last year but it's an exercise in futility only to receive a 'duplicate' response.
What to do with these duplicate app updates? Close the Mac App Store app. If you wait a few hours, the unneeded updates simply disappear. It's a band-aid, not a solution. WWDC can't come fast enough.
It's been merely hours since news broke about Apple's (possible but reportedly imminent) acquisition of Beats Electronics but already the internet is abuzz. Once you get over the $3.2b price tag, one question lingers - why? Let's beak it down.
Apple typically acquires companies for three reason, the employees (acqui-hire), patent acquisition, or technology and manufacturing. Very rarely does Apple buy a company with the intentions of taking their product and slapping an Apple logo on it. Siri is one of few exceptions that come to mind, but that was integrated as a feature into the iPhone 4S, not as a standalone product. Take a look at this page and see for yourself.
Does Apple want to slap an Apple logo onto Beats headphones and call it a day? Not bloody likely. And that certainly wouldn't be worth $3.2b.
I'm not currently aware of any Beats Electronics' patents Apple would be interested in or could not design around. So I'll cross patents off the list.
Apple's earbuds are pretty good. Some people might tell you otherwise but they've come a long way since the first pair sold in 2001. For where I sit, Apple's Earbuds have a better reputation for build quality and price than Beats headphones. I have yet to come across clear evidence to declare a winner in sound quality. Some people prefer buds, some prefer over-the-ear headphones.
If Apple wanted to sell over-the-ear headphones, I'm sure they would have in the last 13 years. This acquisition is not about getting into the large headphones business although they could more easily now than ever. Other than sound quality (debatable), what Apple's earbuds are missing is wireless connectivity. Apple doesn't ship Bluetooth headphones. It's been a long-requested feature. But Apple's more than capable of releasing their own wireless earbuds and $3.2b certainly isn't worth the investment if that was the main reason.
From what I've seen, Beats headphones aren't made out of any unique materials and I'm assuming they're manufactured much the same way other headphones are.
But we're focusing too much on headphone hardware. Beats also supplies speakers for laptops and cars as well as their own earbuds. Can't think any of that would peak Apple's interests.
What Apple may be interested in is the (newish) Beats Music. It's a music streaming service that's better than a lot of offerings out there including Apple's iTunes Radio. Beats Music does a great job at song curation and it seems to be a hit with customers, especially those under 30. That's a key demographic that Apple has always needed to target, more important now if you consider Apple's near venture into wearables.
Beats has demonstrated that it knows how to build products and market them successfully to customers under 30. They can do it with wearables and with content. The thought of another company being as successful as Apple in their core demographic and with companion products likely doesn't sit too well.
Beats' employees, especially designers and marketers, would be an invaluable asset at this point considering the chatter about Apple's plans for wearable devices. Beats Music will likely be folded into new and existing iTunes software and services.
Some of Beats technology may make its way into future Apple headphones and Beats speakers may be in your next MacBook Air.
Say goodbye to the rest.
A sample of Brent Simmons' rules we Cocoa (Touch) developers should all be following. Some great stuff in there.