Radosław Pietruszewski makes the case for brevity:
Some people say that “clarity trumps brevity.” And they’re absolutely right. Except for the fact that brevity can be a factor in clarity. Verboseness doesn’t come for free…
The trick in finding the sweet spot is to maximize the things that explain what the code does and remove as much noise as possible — the things that don’t really add information.
Alex Vollmer, A New Future?:
This is going to sound funny, but I think the tactile pulsing feature of the Apple Watch is one of its most intriguing. It got me thinking about how, paired with the right software, it could be a fantastic way to teach a wearer certain timing-related skills…
As a musician, that pulsing action might make for a great silent metronome. Instead of playing along with a monotonous click, you could simply time your playing with the watch's pulse. Music teachers always talk about “feeling the groove,” this would make it a literal reality.
Tim Schmitz, Reading the Size Class Tea Leaves:
Both the iPad Air and the iPad mini have a “regular” size class in both dimensions, which implies that Apple is at least leaving room for something larger than the iPad. The likeliest explanation is that they’re keeping their options open for shipping larger devices in the future. Maybe a larger “iPad Pro?” Or perhaps an Apple TV SDK, in which the TV has a “large” size class.
TETHR is free and looks pretty good from the screenshots. (Scroll down on the page.)
(Via John Nack.)
Pablo Bendersky, Apple Watch Event Thoughts:
While iOS 7 and 8 have a visual style that do not require pixel perfect mockups, iOS 7 was touted as designed for retina displays, and the recommendation was to use retina assets (like 1px lines) which might not look good on the 6 Plus.
I would think that every programmer thinks in powers of two — more so than in powers of ten. (Is 100 a round number? Hell no. But 64 is.)
The @3x thing makes me feel like one of those computers in the original Star Trek that Kirk destroys by feeding it bad input. Does. Not. Compute. Can’t. Divide. Three. By. Two. Help. Me.
Pop. Bang. Fizz. Lights out.
(Okay. I’ll adapt.)
NSScotland (they’re sponsoring this blog this week) has a nice idea: gift tickets. Buy a ticket for someone who can’t afford it — a student, for example. Other conferences should do this too.
Jared Sinclair, Unread is Now a Supertop App:
I’m proud of the work I put into Unread, and can’t wait to see what Supertop does with the foundation I laid down. Unread has the cleanest code I’ve ever written for a personal project, so I’m hopeful that it won’t be a burden for Oisin and Padraig to wander through it.
I admire both Castro and Unread. This looks like a great fit.
Will you have to write WatchKit apps in Swift? Seems that would not be necessary on a technical level, but it feels like a possible Apple-like move to encourage adoption.
It’s crazy to me that with interest in Apple at such a high, a publication that covers Apple couldn’t make enough money to retain its staff.
It seems to me that Macworld had a giant advantage over almost everything else.
Is it just that it’s hard to make enough money to run a quality publication? Even with the advantage of being Apple-centered?
Now that Swift is at 1.0, I need to set a policy for when to use Swift code and when not to.
Swift is a peer of Objective-C and you can ship apps written (all or in part) in Swift. And I expect that the share of Swift code will grow fairly quickly.
I also expect that, once I’m good at Swift, I’ll be more productive than I am with Objective-C.
That’s a big premise to accept, and it’s not based on experience yet — I’ve written only a few hundred lines of Swift code, and slowly — but it looks like it’s true. There are classes of bugs that won’t compile in Swift. It has very nice things like type inference and optional chaining that cut down on the amount of code I need to write and maintain.
But this means I’ll be less productive as I get up to speed. There’s never a good time to be less productive, but developers are used to making this particular trade-off: adopting a new thing now has benefits later.
So my policy is this: new code will be written in Swift.
There are exceptions, though. The things Swift can’t do will have to be written in Objective-C. (Luckily these are fairly rare.)
And there has to be a time limit. I forget who proposed the 45-minute rule for CSS, where you give up and just use a damn table for your layout. I don’t want to be too quick to punt when using Swift, because it means I won’t be learning as much as I could be (and I need to become expert: that’s the point), but I also can’t let my productivity go too far from what’s normal.
I’ll give myself two hours of banging-head-on-disk, then punt. As a rough guideline. (I’m not actually going to use a stopwatch.) This number may change, but it’s important to have some limit as I’m doing this.
Also: I got the latest version of the Swift book and I’m re-reading it. Just because it feels right. You probably don’t need to, but I feel like I do.
I’ll also keep the known issues from the Swift release notes handy, for when I do get into a weird situation. And I’ve added the Swifter site to my favorites bar, for easy lookups.
Say you have an app connected to a web service — like Twitter or Facebook — and you create a native Apple Watch app.
How is the watch wearer able to enter their credentials for the service?
Update 11:40 am: The answer, as many people have pointed out, is that this is one of the reasons the Watch requires an iPhone. I’m curious about the details. I’ll be patient.
Macworld magazine has meant so incredibly much to me over so many years. And it’s not really closing — but they just let almost everybody go and they’re dropping the print magazine. So it’s finished as the Macworld that I loved.
More important to me, though, are the people I’ve gotten to know a little bit. Great individuals, great team. I feel bad for them for this very unhappy surprise — but I also have no doubt they’ll go on to do awesome things. And better things.
If we could deliver a standing ovation via internet as these folks leave this particular stage, we would. It’s so deserved.
PS In case you missed it, here’s Jason Snell’s personal announcement.
Airspeed Velocity documents changes to the Swift Standard Library in Xcode 6.1. How we live now is we don’t sleep anymore.
Tim Bray, A Word on NFC:
There is a large and interesting class of problems where pushing bits across narrow gaps is useful. For a subset, requiring actual physical intimacy is a must-have; for the rest, it’s not a problem. So here’s hoping Apple publishes a sensible API in iOS.next.
Off the top of my head, before thinking things through…
I want the watch. I want to write software for the watch. I want the watch. Want.
I think I’ll go for the super-big iPhone. I’m a sucker for screen real estate. Might as well go all the way. (But I might change my mind once I hold one in real life.)
At this point, Apple could, and should, slow down a little. Yearly OS X and iOS releases mean a lot of work for developers. Consider not just the usual updates we need to do — now we have watches and extensions and handoff and a new language. Wonderful things, but also a ton of extra work.
My favorite OS X release ever was 10.6 (Snow Leopard) — that was the year Apple didn’t add any features (except for some very cool developer features such as blocks). Apple fixed a ton of bugs and made everything faster. My hope is that Mac OS X 10.11 and iOS 9 are Snow-Leopard-like releases. If they switched to a longer interval between releases, I would not complain.
I like U2. I thought they were old and tired by the time I was in college (1986). (Their last good album was War, said me.) But now I realize that the young me was a jerk. U2 was and is a great band.
Every time anyone said “intimate” during the event I cringed a little.
I think health and fitness are massively important (doi) and I look forward to these features. But my liberal heart breaks every time I think about how much easier is it for the affluent to be healthy and fit than for people who can’t afford fancy watches. But that’s not a reason not do it. And I’ll be happy to take advantage of those features.
I actually missed huge chunks of the video. I’ll watch it later tonight once it’s available.
I’m massively worried that Xcode 6 and iOS 8 are not really ready for release. But then I have this same worry every time. I’m glad it’s not my job to make that call. Are the bugs fixed?
I hope bars get in on Apple pay.
I want the watch. Waaaaant.
NSScotland, the Scottish Mac and iOS development conference, runs October 25-26 this year in beautiful Edinburgh.
Sessions include Rob Rix on polymorphism in Swift, Drew McCormack on making magic, honorary Scotsman Graham Lee on testing at Facebook, Sally Shepard on developing for the AppleTV, Johnnie Walker on iOS image processing, Eric Knapp on CoreMIDI, and Glasgow’s own James Thomson on indie survival strategies.
We’re also delighted to be running a Swift kickstart tutorial from Daniel Steinberg on Monday October 27 (the day after the conference).
The conference is limited to 100 and the tutorial to 50 — tickets for both are still available.
And if you’re coming to Scotland, why not take an extended vacation? There’s a reason they put Hogwarts here, after all — it’s lovely country. Worth the trip. :)
Mustapha Hamoui, Blogs Are Cool Again:
If you choose to follow a blog, no company like facebook can decide whether or not you can read its posts. So don’t hesitate to blog away.
My favorite part, self-centeredly, is that Mustapha calls me a “known iOS developer.” Like “known Communist.” Love it. :)
I go to the <script> section and start writing routines. Just as if I were going to run it from my desktop, which in a very real sense I am. It’s just that today my desktop exists mostly in my mind. Which is where it always has been.
I don’t think Dave is using any of the frameworks like Backbone, Ember, or Angular. (jQuery maybe? I don’t know.) He does use Bootstrap, I believe.
But that’s just me — I like to minimize dependencies. And I don’t like the idea of a browser downloading 100K (or more) of code when it could be 10K. And I don’t like the idea of updating my code just because a framework made a breaking change but I need to upgrade because there’s also a security fix. (Would this happen? I don’t know. Could just be paranoia on my part.)
On the other hand, there really is something to be said for these frameworks. If they take care of the boring parts, and then just get out of the way and let me concentrate on the unique parts of my app, then that’s a win.
* * *
Web apps make such an interesting contrast with iOS and Mac apps. With native apps, you use Xcode and the Cocoa frameworks, and that’s that. You might choose between Objective-C and Swift, and you might choose to use some open source libraries such as AFNetworking.
But those choices are few and relatively small compared to all the choices with writing web apps.
You could say that writing iOS and Mac apps is like living in a town where one company provides most of the jobs. (Sure, you could work at the diner, but all your customers work at this one company.)
And writing web apps is like living in New York City, where choice and contrast is everywhere, and sometimes A and B (and C and D) are all equally cool but different.
The web is the cosmopolitan environment.
Tim Schmitz has a nice proposal for viewing Swift headers in Xcode.
All the logic in my API would be packaged as a standalone library and the REST interface will simply expose this logic. I can import and use the library directly in my code, and my applications will talk to the methods in the library without having to go through HTTP. These methods contain 100% of the logic so I won’t be duplicating code neither incurring in unnecessary latency.
If I understand correctly, then this means that my several different Node/Sinatra/whatever apps would each have their own copy of this library. I hadn’t thought about that approach, and I’m a little worried about how I’d manage making sure it’s up-to-date in each place. But that kind of thing (via Ruby gems, npm, Git, Mercurial, etc.) is supposed to be easy these days.
The approach I imagined is that an API server would play that role, and the various apps would talk to the API server via http to do the common things. (And the in-browser app would talk to that API server too.)
I hadn’t thought of Santiago’s approach. Definitely worth considering.