Vesper, New iPhones, and Editing Fixes

Vesper 2.004 is on the App Store.

The two big changes are support for iPhone 6 and 6+ screens and editing fixes.

Supporting 6 and 6+ wasn’t much work. I had done most of this work before the iPhone announcements, and it was a matter of fixing the couple spots that assumed a 320-point-wide screen. The remaining thing to do was to add launch images for the 6 and 6+. Simple.

The editing fixes were a bigger deal. The first thing is that Apple fixed some bugs in UITextView in iOS 8. Because of those fixes, I was able right away to remove some of our many work-arounds, some of which were a bit heinous. I ended up removing all of our work-arounds and starting from scratch.

And I was pleased to find that we needed very few work-arounds — and small ones, well-contained and easy-to-understand, not like the previous work-arounds — to make editing of long notes much, much better. I’m very pleased, and I thank Apple for attending to this. It’s much appreciated.

At the same time, I also learned from a person-who-can’t-be-named a couple of things that seem to help with UITextViews.

  • Set allowsNonContiguousLayout to NO on the layout manager. It may be NO by default, but set it to NO anyway.

  • Avoid using contentInset — use textContainerInset instead.

So: not a huge release, but a very welcome one. Dealing with editing bugs has been a giant time-suck for me, and I’m so glad to finally get past that, and I think Vesper users will be pleased.

Eric on Web Architecture

Answers About Web App Architecture For Small Teams:

If you are planning on staying a small team (say, less than 3-5 engineers) for a few years, the friction you feel is going to be coming from some place different than communication and coordination between engineers.

When you’re starting out, and when you’re small, the speed at which you can make changes and improvements makes all the difference in the world. Having a bunch of separate services with interfaces and contracts just means that you have to make the same change in more places and have to do busywork to share code.

Timeline Algorithms

I’ve never stopped thinking like an RSS reader developer. A habit of nine years is difficult to shake.

For many years what I wanted to do was develop an algorithm for the reader that would pay attention to what you pay attention to, so that it could bring to the top things likely to be most important to you.

I never got that far, which I regretted for years.

But now I wonder if that would have been the right thing to do. These days I hear complaints that you don’t see everything on Facebook from the people you’ve chosen to follow. And Twitter seems to be moving toward an algorithm-based timeline too, which has people (including me) upset.

At the same time, people do like things like muting features and lists. So it’s not that they’re against filters and organization — it’s that they don’t want these imposed from the outside.

These days, were I writing an RSS reader (I’m not), I think I’d skip developing an algorithm based on the user’s attention — instead, I’d focus on making it really easy to filter out the things you don’t care about, and to highlight the things you’re more likely to want to see.

And not try to come up with some algorithm which would have the effect of bugging people and making them feel like they were missing things. Since they would be.

Online Life

Dave Winer, The frenzy of online:

This isn’t communication, or sharing. It’s growing more and more frenetic every day, it seems. And more pointless.

I’ve often had the thought that our social networks are the same thing every day, with just slightly different details. When I skip them for a few days, I find that I have absolutely no feeling of missing anything.

Here are some things that don’t give me that same-thing-every-day feeling: making things, reading books, and talking to people in real life.

(Currently reading The Quiet American.)

On Criticism and Enjoyment

David Gerrold (one of my favorite science fiction writers):

Comic Book Guy isn’t having any fun. He’s bored — and he’s boring. Bart and Milhouse are having fun. They’re excited and interested. They get it — it’s about being a kid again. The whole point of a comic or a book or a movie or a TV show is to be a kid and have fun. It’s about trusting the author/filmmaker to take you on an exciting journey — not a dark ride, but a journey of discovery. You can’t do that if you’re watching the lighting, the editing, the camera angle, the dialog, the acting — you gotta let go and be a kid again.

Full-Text Search

New Yankee Codeshop shows how to do full-text search on iOS and OS X using SQLite and FMDB.

The Indie Developer’s Wilderness

Gus Mueller:

However much time I’ve been doing this for, and no matter how much practice I put into it, there’s one thing that always sneaks up and pulls the rug right from under me. It’s usually between major releases, but not always. It’s a period of time where I’m pretty lost, and I don’t know what to do. I have feature lists, I have open bugs to fix, and I have an outline of where the app is going. But I feel mentally incapacitated, like I’m getting nothing done.

Rock Stars

Fellow Q Dave Wiskus talks about putting on a good show in Rock Stars.

Apps are the showbiz of today.

Manton on Microblogs

For a new project, Manton Reece is defining a microblog post.

Manton and I care about many of the same things. (We’ve known each other since the ’90s when we were both in the Frontier community.) Among the things we both care about are the virtues of decentralization and of owning your own writing.

I don’t have much in the way of details of what he’s working on — but it sounds like a project I’ve had in the back of my mind for quite a while. Since I’m more interested in the thing existing than actually doing it myself, I’m very happy to see Manton working on it.

* * *

Is the web we lost gone forever? Was it a brief golden age before the rise of Facebook and Twitter and The Algorithms of Engagement?

Or is the current period a brief blip in time, where we turned the wrong corner and now we’re getting back on the right road?

I used to think that the very structure of the web meant that it was always inevitable that we’d get back to the great web. I’m no longer that kind of progressive — I realize now that loss is real, and usually permanent, and that good things have to be fought for, not by a handful of heroes but by a bunch of regular people like me and Manton.

[Sponsor] Hot-patch and Control production code with Rollout.io SDK (iOS developers)

In today’s mobile landscape, a lot of resources are directed towards building better quality apps — from beta testing platforms to distribution systems and even app performance monitoring solutions. But none of these solutions help developers while their app is in production.

With Rollout.io, developers can quickly react to their users by remote-controlling their app’s settings and parameters, as well as fix and contain errors and issues in real time — without waiting for a full release cycle.

Capabilities:

  • Contain & hot-patch production bugs
  • Create analytics events on the fly
  • Messaging
  • SDK toggling
  • Advanced logging and debugging
  • UI changes (buttons, images, etc)

See how it works:
https://www.youtube.com/watch?v=4nT-1Nw0ihw

Radek on Swift Methods

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 on Developing for the Apple Watch

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 on Size Classes

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.

iOS Design Kit

TETHR is free and looks pretty good from the screenshots. (Scroll down on the page.)

(Via John Nack.)

Pablo on the Apple Event

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.)

Gift Tickets to NSScotland

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.

This Acquisition Makes Total Sense

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.

WatchKit Speculation

Awkward Hare:

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.

What I Can’t Get Over

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?

Swift Policy

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.

Archive