Tag Archives: swift

Swift 3 churn

Back in July, I posted this to my microblog, which was cross-posted to Twitter for some additional discussion:

Not shocked that Swift classes won’t be subclassable by default. But it underscores Swift’s priorities. And for that reason, I’m out.

The “I’m out” was meant as a Shark Tank reference, and not to be taken too seriously. But I was serious about taking a break from Swift until version 4, when it would at least be more stable. Daniel and I followed up that week with a more in-depth discussion on Core Intuition 242.

A few days ago Craig Hockenberry posted about how the rapid pace of improvements to Swift can get in the way of learning the language and using example code:

It’s gotten to the point where every time I come across some information written in Swift, especially on Stack Overflow, I cringe. I know that I’m going to have to not only figure out the code, but also which version was used for the answer.

I have absolutely no regrets sticking to Objective-C. As Swift 3 was wrapping up, it seemed that the churn around syntax changes was even worse than I feared. From an Apple dev forums thread at the time:

For the expected quality of software in a third-generation project in late Beta, Swift 3 has become a trainwreck of Microsoftian proportions–at least in terms of process and expectation. Many of us devs are spending 90% of our time not developing our app, but babysitting Swift and trying to understand so many unvetted changes.

That settled down with the final Swift 3 release, but I expect many developers won’t upgrade from Swift 2.3 until Xcode forces them to. There’s even a whole book by Erica Sadun on migrating code.

I still consider Swift a beta language. I just hope that the Swift team and community recognize that this level of instability isn’t acceptable forever. A programming language is not an iOS or macOS release. There shouldn’t be a new major version of Swift every year.

Core Intuition 267

This week on Core Intuition, Daniel and I talk about the halfway point to my Kickstarter campaign, running ads, and more:

Manton talks about marketing for the Kickstarter, how many people watch the video, and how to transition from marketing the passionate philosophical backers, to making a case for the sheer utility of the product. They talk about modern advertising technology that allows hyper-focused delivery, and follow up on Chris Lattner’s departure from Apple, and the exciting opportunities he will likely have at Tesla.

The last segment of the show is about Chris Lattner going to Tesla. We recorded before we listened to the latest ATP, but our conversation still holds up as pretty relevant. Hope you enjoy it.

Core Int 242, Swift, and verified Twitter

From the show notes for today’s episode:

Manton reacts to negatively to the Swift 3 decision to disallows subclassing by default, while Daniel tries to see the bright side. The two discuss Twitter’s new invitation to apply for @verified status, and Daniel’s attempt to do so. And they quickly touch base on the upcoming Apple-sponsored reality show, “Planet of the Apps.”

Believe it or not, I was kind of holding back a little in my Swift ranting. But it was the most critical I’ve been on the show. And it’s totally okay for you to disagree! Maybe even good for the platform if you do.

Swift server benchmarks

Interesting Swift web server article comparing Vapor, which I tested last week, to other web server frameworks:

This first post will cover input, i.e. request data. Fetching input from a request, ensuring it is the correct type, and most importantly, not crashing. These are common tasks that most web developers deal with daily. All of the frameworks have their own unique way of doing these tasks–Let’s see how they contrast.

There is some further discussion from fans of other languages in the comments. Overall I think the article was fair. I’m not sure about the focus on “crashing”, though. This seems like a carryover from pro-Swift arguments on the desktop or mobile, and it has less relevance on the web.

For some web apps, it might be fine to throw an exception on bad input data, since it’s caught automatically and returned as a 500 error. I wouldn’t call that a crash anymore than I would call it a crash for a Mac app to present a generic error dialog on unexpected errors.

Core Intuition 234 and Vapor

We published Core Intuition 234 today, with a follow-up discussion on Swift, working toward software releases, and more. From the show notes:

Daniel and Manton talk about the question of Swift’s dependence on Objective-C’s dynamism, how it should or will evolve, and their differences in philosophy about Swift and Objective-C. They also take stock of release discipline and managing customer disappointment with an app’s progress. Finally, they talk about the importance and difficulty of winding down old products.

One of the points I brought up on the show — and which I’ve hinted at here on the blog before — is that web developers will push Swift to become more dynamic. There’s a long history of building web server frameworks like Ruby on Rails that depend on dynamically routing requests to controllers and views, and flexible models that automatically adapt from your database schema. These features tend to get messy when faced with a more static, strongly-typed language.

There is good work being done in the Swift web community already, though. Today I spent some time building a sample app with Vapor, which is probably the closest I’ve seen someone get to the usability of existing web frameworks. I’m a little more optimistic now that we might eventually have a single language for server code and native apps.

Swift and sharp knives

David Heinemeier Hansson has a great post today about Ruby’s advanced dynamic features. Some people would criticize Ruby (and Rails) for including “sharp knives in its drawer of features”, but David argues that it’s a worthwhile tradeoff to give developers such power and flexibility:

There’s nothing programmatically in Ruby to stop you using its sharp knives to cut ties with reason. We enforce such good senses by convention, by nudges, and through education. Not by banning sharp knives from the kitchen and insisting everyone use spoons to slice tomatoes.

Given the recent discussions from the Apple community, I couldn’t stop thinking of Swift as I read David’s post. I wouldn’t go as far as saying that Swift is a dull knife; there is a lot to like about the language, and I feel reasonably productive in it now. But David’s “paternalism” line nevertheless rings true to me, that the Swift compiler is trying to protect us from ourselves.

New Core Int, Technical Foul, and Timetable

I somehow recorded 4 podcast episodes this week. We just published episode 233 of Core Intuition, where Daniel Jalkut and I talk about the announcements from Google I/O and compare the latest Swift 3 news to our experience going through previous Apple transitions. From the show notes:

“Manton and Daniel react to Google’s I/O keynote, and weigh the threat of Allo to iMessage. They celebrate Apple’s WWDC promotion of 3rd party events, and the increasing speed of App Store reviews. Finally, they reflect on the announced delay in Swift 3’s planned ABI stability, and Daniel’s sudden FUD about embracing Swift.”

It was a big week for the NBA, too, with the first couple games of the east and west conference finals. On the latest Technical Foul, Ben Thompson and I recap round 2, especially the Spurs loss in 6 games to the Thunder:

Ben and Manton are back geeking out about the NBA. This week we talk Manton through the Spurs loss, discuss OKC versus the Warriors, and whether the Cavs are good enough.

And finally, I published 2 episodes of my microcast Timetable earlier in the week. Episode 22 was about dealing with recent stress — trying to see the bigger picture and focus on the good things. Episode 23 was about how to tell when it’s time to move on from a failed product.

Apple’s mindset on Swift dynamic features

I let myself go off into a bit of a Swift rant on the latest Core Intuition. I’ve been doing a lot of Swift development recently. The more I use it, the more conflicted I am. I really love some parts of the language, but it’s not what I would have asked for as a successor to Objective-C 2.0.

Remember when Steve Jobs came back to Apple and compared NeXTSTEP to constructing a building by starting out on the 20th floor, with so much of the foundation and common patterns already taken care of for you? Cocoa allowed apps to be built significantly faster than before. Steve said at Macworld Expo in 1997 that the goal was to “eliminate 80% of the code that every developer has to write for their app.”

Swift is not like that. Swift’s priorities are correctness and stability. These have more indirect benefits to developer productivity than we saw going from Carbon to Cocoa.

When Marco Arment wrote about Swift last month, he mentioned wanting a language designed for high-level apps:

Objective-C wasn’t much better for this, but I think we could’ve done better than Swift if the most important goal in Swift was maximizing real-world developer productivity when writing modern Mac and iOS apps. Swift does a little of that, but gives up a lot to also serve lower-level, more clever, language-geekier goals.

This weekend, Brent Simmons has a new post about the loss of dynamic features in “pure” Swift:

What makes me nervous is Swift’s emphasis on type safety and on compile-time resolution. As long as we also have what we need from Objective-C, then that’s fine — then we still get xibs and storyboards, the Responder Chain, and so on.

I hope Brent’s right that this will be a core part of Swift 4. Leaning on the Objective-C runtime feels like a temporary solution because it only exists on the Mac and iOS. Great web frameworks like Ruby on Rails, for example, can’t be built without relying on a more dynamic language. (And to me a great promise for Swift is being able to use it everywhere.)

Daniel Jalkut followed up with a more optimistic post. He thinks Apple is on top of this, even as he acknowledges the clash between existing frameworks and the new language:

Some major design priorities of the Swift language, namely type safety and compile time dependency binding, are at odds with the design priorities of 20 years of evolution in Apple’s frameworks. How and if that disparity will be reckoned by Apple remains to be seen.

I think it’s telling that the “dynamic” keyword isn’t even mentioned in the main language guide. Anything related to Objective-C is off in a separate set of documentation, which includes discouraging statements such as “Requiring dynamic dispatch is rarely necessary” and “use of the performSelector APIs is discouraged”. For Swift to thrive in the future, as a great language for newcomers and long-time Mac developers, Apple will have to compromise on that mindset.

Core Intuition 225

Episode 225 of Core Intuition is out now. We talk about the new iPhone and iPad news from Monday’s Apple event, plus Swift. From the show notes:

Manton orders his dream phone, the iPhone SE. Daniel reflects on the growing allure of Swift, and the two discuss the risks of either adopting new technologies too soon, or holding on to the past for too long.

Also there’s this line from Daniel in the podcast that I like:

We have to be tuned into the future and tuned into the past to really do great work.

We pull in some history from Daniel’s time at Apple, and from our experience building Mac apps in the 1990s and early 2000s, and how it relates to the current Swift transition. Hope you enjoy it.

Tim Cook, Swift, and the return of blogs

Rob Rhyne wrote an essay last week that caught my attention, on Tim Cook and the incredible pace of new major OS versions at Apple:

“Still think Apple isn’t innovating enough under Tim Cook? Don’t let an app developer hear that talk—they want a vacation, and the end of 2015 showed no signs of relief.”

But I found it significant for another reason too: Rob hadn’t blogged on that site in over 2 years. He picked it up as if no time had been lost, hitting the ground running with a great post.

He’s not the only one starting to blog more. Matt Gallagher just rebooted Cocoa with Love after 4 years since his last post. Swift was a good excuse to resume writing, but he had wanted to continue the site anyway.

Most of my favorite blogs have new posts every day, or at least once a week. New posts bring more links and traffic, giving the blog life and momentum.

There’s no single correct way to blog, though. Blogs are forgiving. If you’ve neglected your blog for a while, you don’t owe anyone an apology. Just hit command-N in your favorite text editor and start writing.

Core Intuition 210

On the latest Core Intuition, we talk about open source Swift, it’s potential for web server frameworks, and more about blogging tools. From the show notes:

“Daniel and Manton react to Swift’s open-sourcing, and the extent to which it adds momentum to the language and increases its appeal. They also discuss the open-sourcing of Microsoft’s MarsEdit-esque blog editor, Windows Live Writer.”

There were also a few new jobs posted to jobs.coreint.org yesterday. Check them out if you’re considering a change for 2016, or just curious what is out there for Objective-C and Swift jobs.

Swift and Core Intuition 209

Like many developers, I’ve spent the morning looking over the Swift open source release. I continue to be intrigued and look forward to working Swift into more of my routine.

On today’s Core Intuition, Daniel and I talked about Swift for about half of the 50-minute episode. We recorded the episode yesterday afternoon, before the open source announcement, so we’ll be following up next week on everything that has changed. I bet there will be some more progress in Swift web server frameworks by then, too.

A diverse community through writing

I read a lot of weblogs. RSS is a great way to keep up with sites that update infrequently, or that aren’t popular enough to bubble up on Twitter with dozens of retweets. But the Mac and iOS community has grown so much over the years. I know there are many new writers who haven’t been on my radar yet.

Brent Simmons has posted a great list of tech blogs by women that I’m going through now. There should be something there for anyone interested in development or design:

“I made a list of some blogs I already knew about, and then I asked my friends for more, and they totally came through.”

The list grew to include over 50 blogs as suggestions arrived to Brent via Twitter. I’ve already subscribed to a bunch and look forward to discovering even more.

One of my favorite new blogs is the travel blog complement to Natasha The Robot, which made Brent’s list. Natasha was recently hired at Basecamp, runs the This Week in Swift newsletter, and writes on her new blog about working remotely. From a post about taking her laptop to restaurants in Europe:

“The nice thing about this is that I get a really cool and inspiring office for a few hours – each cafe or restaurant has it’s own vibe, people, music and I don’t feel rushed internally knowing that I need to go back to my apartment or coworking space to actually work.”

When I quit my day job this year, it was partly so we could travel more without worrying too much about my work schedule, outside of when the kids are in school. In fact, just days after I finished writing my two weeks notice blog posts, we went to Europe and started a private family blog about the trip. So I’ve been inspired by Natasha’s blog as she shares her experience working in different cities.

And that’s a theme you’ll find in many of the developer-oriented blogs on Brent’s list. Wanting to get better, learning something new, and then sharing it with everyone else. Take this advice from Becky Hansmeyer, who wrote a daily series of posts about what she learned building her iPhone app, one post each day while she waited for her app to be approved by Apple. From day 4, on design and color:

“I think the biggest thing I learned in choosing colors and fonts for my app is not to get too hung up in making comparisons to other apps. I spent a lot of time looking at my favorite apps like Overcast and Tweetbot and thinking about the decisions the developers made, and as a result I wound up feeling like I had to make those same decisions. But that was stupid because my app is my own and is also designed for a much smaller market.”

Or this quote from Kristina Thai, who wrote a post about preparing to give a talk for the first time:

“My presentation didn’t flow, it was jagged and very rough around the edges, but I kept at it, made some changes and it got better. And better. And even better. And then I practiced it in front of a couple of friends who gave me even more feedback until I was ready.”

Kristina also gave a talk called Become a Better Engineer Through Writing. You can get a sense of the talk by downloading the slides. It covers the value to programmers in keeping a private journal, why you might write tutorials for your site, and makes a strong case for blogging.

Blogging isn’t difficult, but it’s still not yet as easy as tweeting. By creating a blog, you’re making a statement that you care about something. As I go through Brent’s list of bloggers, that’s what I’m looking for: what does the author care about, and what can I learn from or be inspired by in their writing? Because the more diverse our RSS subscriptions are — the more varied the opinions in what we read and share with others — the closer it gets us to a strong, healthy community.

I think it’s a bust

The movie Draft Day doesn’t really have any business being good, but somehow it is anyway. I don’t even like football that much — who has time for it when there’s basketball? — but I’ve now seen this movie several times and love it. The movie actually gets better instead of worse on multiple viewings.

It also has a number of memorable lines. One of them is this, said by Kevin Costner’s character about the college football star who everyone thinks is the next greatest thing: “I think he’s a bust.” Five simple words that undo all momentum.

And unfortunately that’s still how I feel about Swift. I’m following Brent’s blog posts about learning Swift and I’m trying to come to terms with whether to adopt the language, and I finally got it. I already have a capable quarterback in Objective-C, and I’m not ready to rebuild my roster yet, risking everything on a young language with so much promise but less real-world success.

No matter how much Swift has improved, no matter how much everyone fawns over it, I still can’t shake the feeling that it’s a hype that someone else’s team needs. For me, it won’t end up solving the problems I have when building apps. For me, it’s a bust.

Clever code and WWDC

In his 9th essay about avoiding crashes in your code, Brent Simmons writes about learning to be even less clever:

“But over the years I’ve come to think that I should write code that’s about 10% as clever as I am. And I’ve come to believe that true cleverness is in making code so clear and obvious that it looks like nothing at all.”

I’m in San Francisco for WWDC this week, but without a ticket again. I took some time this afternoon — miles away from the hotel and Moscone — to reflect on what I’m doing here and what I need to do next. I’ve been to WWDC many times; my first was in 1996. And it has taken almost all of those years for me to understand the truth of Brent’s statement about being clever.

I also believe that a programming language can either encourage or discourage clever code based on the syntax it allows. I saw it with Ruby — programmers intent on fitting as much logic into a single line of code as possible. I think I see it with Swift as well, in operator overloading and maybe even a kind of rejection of Objective-C’s notorious verbosity. We’ll know for sure if we eventually see a Swift book in the pattern of JavaScript: The Good Parts.

Core Int 180 and Slack

We posted this week’s Core Intuition late last night. This episode is all about WWDC tickets, our plan for San Francisco, and when we’re going to adopt Swift.

We’re also trying something new for listeners, or anyone who wants to talk about programming, WWDC, and other Mac and iOS topics. You can get an automatic invite to our Slack channels for the show by visiting chat.coreint.org. Feel free to join in! I’ve been impressed with how well Slack works for this, and the great discussion that’s already happening there.

Swift or Android

I was nodding my head while listening to the latest Developing Perspective yesterday. David Smith talked about all the work to update his apps for iOS 8, starting on Apple Watch apps, and so taking the pragmatic approach to keep using Objective-C rather than dive into Swift.

Then I read this by Russell Ivanovic on getting started with Android development:

“It’s really not that hard to get started, but you have to be realistic. If you want to get somewhere, you’re going to have to invest some time. If you want to build a viable business on Android like we have, that might end up being a lot of time. I really feel like 2015 might be the only window you’re going to get though, before Google Play becomes as hard to succeed in as the iOS App Store.”

And I thought, getting up to speed with Swift is probably not that different than learning Android. I’ve programmed Java before, but don’t know the UI frameworks; I know the Cocoa frameworks, but have never programmed anything significant in Swift. Both would require setting aside current priorities and investing some time in a new language or new tools.

If I had to build an app in either as quickly as possible, choosing Swift would certainly be faster. I’m just not sure it would actually be a better use of my time than poking around in Android.