0xdeadbeefI mostly write about Swift, Objective-C, iOS, open source, and other software development topics. Sometimes I write about the ethics of tech, labor, and politics. I also write personal essays and notes on what I'm currently reading. Looking for something specific? You can view posts by tag, or search this site.
Subscribe: RSS, JSON feed, Apple News
JP and I released a special, off-schedule episode of Swift Unwrapped today. We welcomed Doug Gregor from the Swift Core Team back to the show to discuss the major new features coming in Swift 5.1.
I’m excited to share that my good friend and talented artist, Lisa Sy, and I have released a new sticker pack for iMessage! It is based on her excellent web comic, plurals and noun — a comic about queer and weird things that happen. It’s free and you can download it here.
I recently released a menu bar Mac app called Red Eye. It’s free and you can download it here. It prevents your Mac from going to sleep. Yes, it is a clone of the beloved Caffeine. And yes, it is the second menu bar app that I’ve made recently. It is notarized by Apple, so you shouldn’t have any problems installing it. I hope you enjoy it!
I’ve been eating vegetarian (and often vegan) for a decade now. I don’t talk about it much. This is a choice I’ve made for myself and my own reasons. What I never imagined happening is the growing popularity and wide availability of vegan/vegetarian food. It is simply remarkable.
Continuing from my previous post, there is a bug in NSStatusItem that I forgot to mention. Thanks to Michael Tsai (tweet) for pointing out this workaround.
I just pushed a small update to Lucifer. You can download it here.
This isn’t complicated, but I found it confusing. Perhaps I am spoiled by the more modern APIs in UIKit. When writing Lucifer, a menu bar app, I wanted to have different actions for left-clicking and right-clicking on the button in the menu bar. To my surprise, this was much more cumbersome than I expected.
I deleted my LinkedIn account, well sort of. I kept my account open, which I will explain below, but I left it mostly empty. You could say I am now officially linked out.
A friend recently sent me The short instructional manifesto for relationship anarchy by Andie Nordgren. It is short and a good primer on relationship anarchy if you are not familiar. Take a look.
I made my first Mac app — Lucifer. It is a menu bar app that allows you toggle Dark Mode on and off in macOS Mojave. To be honest, it feels like a stretch to actually call this a Mac app. It is less than 100 lines of code in a single AppDelegate.swift file and the meat of the program is an AppleScript that tells System Preferences to enable or disable Dark Mode. As an iOS developer, much of the experience was familiar. The most salient aspect, however, was learning the frustrating and obscure details of app sandboxing, the “hardened runtime”, and app notarization — altogether it was like visiting hell and giving Satan a bubble bath. Appropriate, I suppose.
I intend to start a new series of posts called Reading Notes where I publish notes, excerpts, and thoughts on what I’m currently reading. My goals are to better document my notes and thoughts on what I’m reading for my future self, and give myself a reason to write more blog posts (in general, but also more non-technical ones). I also hope to inspire you, dear reader, to read some of these books and essays.
I tweeted a joke about estimating software engineering projects while I was at work during a team meeting for a retrospective on a project we recently shipped. The project was not completed within our original estimations. (Did I even need to say that?)
Here’s the list of the books I read in 2018. There are 36 in total. At first it seemed like a small number to me. However, that averages to three books per month, which actually feels like a lot. In fact, I’m not sure I could read more than three books each month. There was never a time last year when I wasn’t reading something, and I often read multiple books at once.
Over a weekend recently I built a tiny Mac app (more on that later). What I was trying to achieve required executing AppleScript, like so many things on macOS. It seemed simple enough, but of course new app sandboxing restrictions in macOS Mojave got in the way.
The other day I was debugging a crash in a UI test for an open pull request at work. The bug turned out to be extremely subtle and difficult to notice. I spent way too much time staring at the changes, trying to understand what was wrong. Let’s see if you can spot the error.
There’s a place called North Berkeley Frame in downtown Berkeley on Shattuck. It’s a framing shop and gallery (sort of) run by this guy named Lars. He’s older, probably mid-fifties or early sixties. He has gray hair, a gray beard, and a gentle face. I’ve had him frame some prints and other artwork for me. He’s always helpful in choosing the right frame, and his work is excellent. Like many older folks I know, he loves to talk.
Fifteen years ago today my sister died. Most people don’t know about her — Amy. I don’t talk about her much, because talking about death makes people uncomfortable, especially when the loss was so traumatic for those left behind. I was 14, she was 16. It feels like it happened a lifetime ago and that it just happened yesterday, all at once.
I haven’t read the book, The Four Agreements, but I will eventually. However, simply knowing what the Four Agreements are has been tremendously helpful for me. They may help you, too. I want to write them down to share, but also to remember them better and have a reference to revisit in the future.
A common scenario in app development is to build up a list of objects, perhaps to display to the user or for another purpose. Maybe you’re fetching data from a database to display, or constructing fields to display for an interface. Consider the iOS Calendar app, for example. When you add a new calendar event, the form displays all the fields you can fill-in — title, location, date and time, notes, etc. However, when viewing an existing event all you see are the completed fields while the uncompleted fields are hidden.
The mayor of San Francisco called out feces on the sidewalks as a core problem to address in the city and wants homeless folks to “at least have respect” and “clean up after themselves”. It’s an unfortunate response, but I’m sure a lot of folks agree with the sentiment. No one relishes walking through the dirty streets in this city and it certainly is a concern, but this kind of rhetoric is actively harmful. It deliberately shifts responsibility for the problem onto the victims and away from the system that produced it. Homeless folks are among the most vulnerable in our society. In addition to their lack of housing, persistent precarity, mental health issues, and emotional struggles, the city is now going to ask them for respect and cleanliness?
One of the major changes in Swift 4.2 is a change to the calling convention. But what exactly does that mean? Why is it important and why would you want to change it?
I’ve known about the Tor Project for a long time, but I guess it’s been awhile. 😅 The last time I was actively using Tor was with Vidalia, which was apparently discontinued about 5 to 6 years ago. Ha! Whoops.
Net Neutrality is officially over in the US. As the EFF notes, it will likely manifest as a slow, painful decline of the Internet. We can call congress to demand that they reverse the decision and act in the interests of the people. But whether or not that succeeds, everyone should be using a VPN regularly now to fight against the growing threats of Internet surveillance and censorship. We know better than to trust corporations and governments.
I finished reading Chimamanda Ngozi Adichie’s new book, Dear Ijeawele, or a Feminist Manifesto in Fifteen Suggestions. You should read it. As well as We Should All Be Feminists while you’re at it.
Swift Unwrapped recorded two episodes in the Podcast studio at WWDC this year. We had Greg Heo on to talk about our reactions to the announcements from the Keynote and Platforms State of the Union. Then we discussed Swift 4.2 and beyond with Ted Kremenek.
I recently discovered a preference in Xcode’s Navigation settings that makes the ‘Assistant Editor’ much more useful, especially when writing Swift.
I had a great time at WWDC this year, meeting new friends and catching up with old ones. Those experiences are the ones that matter the most to me. The newly announced tech is interesting and fun, but ultimately fleeting and ephemeral.
In a recent episode of the podcast, JP and I discussed the implicit escaping of closures in Swift. As Swift has matured and evolved, the default behavior of closure parameters in functions has changed. Prior to Swift 3, closures parameters were escaping by default. After SE-103, the default was changed to non-escaping.
I’ve removed Google Analytics from this site. I was in a similar situation as Ash Furrow, who just wrote about doing this. I’m removing it because it simply causes more harm than good.
I just updated my blog to use Bootstrap 4.1 from v3.3.7. Its a major version with lots of breaking changes, so it took me a few hours over a few Saturday afternoons to get everything fixed up. That’s also partially why I missed posting something last month.
I’m not interested in being an advertising product for Google to exploit. I’m also not interested in the company’s unsavory practices, in general. I’ve been using DuckDuckGo for over a year now, and I’m incredibly happy with it as a replacement for Google Search — not only for personal usage, but also for implementing a custom search component for this site.
Updated: 05 Jan 2019
When you file a radar for a bug on one of Apple’s platforms, you should (usually) always attach a sysdiagnose. A sysdiagnose provides a lot of helpful information for the person who is trying to understand how the bug happened. Amongst other things, it contains logs from various parts of the OS, and all recent crash logs. Without it, the person on the other end of your report inside Apple may not be of much help. On macOS running sysdiagnose is somewhat common, but what about iOS?
Updated: 08 Feb 2018
Next week’s issue of Swift Weekly Brief will be its 100th and final issue. I started this newsletter a little over two years ago, covering the initial open sourcing of Swift, the 3.0 release, the 4.0 release, and many significant milestones in-between for the language and the community. With few exceptions, there was a new issue every week thanks to the other amazing writers and contributors. The newsletter quickly became an important resource for the Swift community. Because of this, I’m sure many of you will be saddened to hear that the 100th issue will be the last. At least, Issue #100 will be the last issue for me, for now — but if someone from the community is willing to take over this project, it can continue.
Updated: 18 Apr 2018
Epsilon. ε. The fifth letter of the Greek alphabet. In calculus, an arbitrarily small positive quantity. In formal language theory, the empty string. In the theory of computation, the empty transition of an automaton. In the ISO C Standard, 1.19e-07 for single precision and 2.22e-16 for double precision.
The other day I was attempting to use FLT_EPSILON (which I later learned was laughably incorrect) when the Swift 4 compiler emitted a warning saying that FLT_EPSILON is deprecated and to use .ulpOfOne instead. What the hell is ulpOfOne? I read the documentation and then everything made sense — ha, just kidding. The FloatingPoint.ulpOfOne docs generously describe the static variable as the unit in the last place of 1.0 — whatever that means. Let’s find out.
PlanGrid is a productivity app for construction fieldworkers. The easiest way to explain it to software developers is that it’s like an IDE, Git, and GitHub or JIRA — but for construction. Think of all the amazing software tools we have to do our jobs as programmers. The equivalent tools for construction simply did not exist before PlanGrid, and they still have a lot of room to grow.
As software developers, we build software for specific purposes. We anticipate that people will use an app in certain ways. Yet, we often discover that users are behaving differently than we expected. They hack a custom, “unsupported” workflow to workaround an app’s unintended limitations. Once we realize this, we have the power to turn these user workarounds into first-class features. However, sometimes we find that our apps are being used in totally different, unimaginable ways.
At PlanGrid, we recently discovered that the app was being used as a digital archaeological tool.
The Swift type-checker remains a performance bottleneck for compile times, though it has improved tremendously over the past two years. You could even say the type-checker has gone from being drunk to sober. To help users debug these issues, awhile back Jordan Rose added a frontend Swift compiler flag that would emit warnings in Xcode for functions that took too long to compile, or rather took too long to type-check. In Xcode 9, there’s a new, similar flag for checking expressions.
This site used to be hosted via GitHub Pages, but I decided to move to a dedicated host to have more control over how I develop and deploy the site, and how it’s configured. A number of limitations and quirks eventually drove me to migrate away from GitHub pages to my excellent and inexpensive bare-bones host, NearlyFreeSpeech.net. I was also interested in learning to do all of this on my own, rather than relying on GitHub Pages “magic”. If you’re looking to setup your own Jekyll-powered site, or if you’re looking to migrate off of GitHub Pages, hopefully this is helpful.
Data & Society recently released a stunning report, Media Manipulation and Disinformation Online. I highly suggest you read it if you care about understanding the rise of neo-fascism, the ‘fake news’ phenomenon, and manipulation of the media that plagued the 2016 US Presidential Election — and how Silicon Valley, particularly social media platforms, facilitated the rise of the alt-right movement and the spread of fascist propaganda. Don’t let the more than 100 pages deter you. The core report is only 50 pages, followed by a few pages of case studies, and finally a whopping 45 pages of citations and bibliography. (Direct download)
The Swift community has been through some rough migrations. It is frustrating when your project no longer compiles because of API and syntax changes, but it is an entirely different story when your project seg faults the compiler. When that happens, you cannot simply run a migration tool or apply fix-its — your project is broken and there’s little you can do until a fix is released. This is why the swift-source-compat-suite project was created.
Updated: 18 July 2017
Beginning immediately, JSQMessagesViewController is no longer officially supported or maintained. In fact, you may have noticed that it has been neglected for the past year. The most recent release was published almost exactly one year ago today. This is an incredibly difficult post for me to write and I have not made this decision carelessly. This open source project had a great run. There was (and still is) a great community around it, and I’m sorry for bringing this to an end.
Protocols in Swift and Objective-C are a powerful tool to decouple your code. They allow you to specify a contract between classes that consume them, but defer a concrete implementation to conformers. They allow you to segregate interfaces and invert control. One interesting aspect of protocols in Swift and Objective-C is that protocol members can be optional (optional in Swift or @optional in Objective-C). Unfortunately, this comes with a number of disadvantages and diminishes the robustness of your code, so it is often avoided. However, having optional members is sometimes the right conceptual model for your design. How can you design your protocols to provide optional semantics without specifying them as optional or @optional?
In a previous post I discussed strategies for using singletons in a cleaner, more modular way. Singletons are a fact of software development, especially in iOS. Sometimes the design pattern actually is the right tool for the job. In those situations, how we can improve the way we write our own singleton classes?
Earlier this week, the Tech Workers Coalition and UNITE HERE! in San Francisco hosted a panel discussion on how we can use our power as consumers to support hotel workers in the Bay Area and across the United States. The tech industry is full of remote workers, as well as conference organizers that host thousands of conferences each year — meaning thousands of programmers, designers, product managers, and others travel all the time to attend these conferences or attend their own company’s events. By choosing to stay at a fair hotel, you can make a significant impact on an industry where workers are struggling to negotiate fair wages and benefits.
There has been a ton of debate on the swift-evolution mailing lists about access control in Swift. A couple of days ago, the proposal SE-0159: Fix Private Access Levels was rejected. I want to share my thoughts on this, as well as thoughts on the larger story for access control in general. But first, let’s begin with a brief history of access control in Swift.
A few months back, JP Simard and I decided to start a podcast about Swift — the language itself, its evolution and development, the Swift.org open source projects, and general Swifty news. There are a ton of great podcasts out there about developing for Apple platforms and Apple news, but there’s nothing exclusively about Swift the language. In many ways, this podcast is an extension of and commentary on the Swift Weekly Brief newsletter. However, we’ll be doing deep dives on various topics and elaborating on concepts in greater detail. I’m excited to share that we launched Swift Unwrapped yesterday with Spec.fm!
In my previous post I mentioned writing adaptive code. That is to say, writing code that is easy to change, code that is malleable. It’s like creating adaptive user interfaces but for all of your classes, modules, and other components.
In software development, singletons are widely discouraged and frowned upon — but with good reason. They are difficult or impossible to test, and they entangle your codebase when used implicitly in other classes, making code reuse difficult. Most of the time, a singleton amounts to nothing more than a disguise for global, mutable state. Everyone knows at least knows that is a terrible idea. However, singletons are occasionally an unavoidable and necessary evil. How can we incorporate them into our code in a clean, modular, and testable way?
Today I found out that I’m part of a class action lawsuit against a service that I never signed up for called TalentBin. As you have likely experienced, most recruiting in the tech industry is debase, disingenuous, boilerplate garbage. But this — this is definitely a new a low.
Let me list the ways that burnout happens in this industry, and especially in open source. No, I don’t need to. Because you know them already. I’m not burnt out, I promise. I’m reprioritizing, just letting you know.
A few months ago, I spoke at Swift Summit in San Francisco. The conference has a reputation for providing high-quality talks, and this year was no different. Fortunately, I was able to see nearly all of the talks and not a single one disappointed me. It was such a great conference. The video and full transcript of my talk are now available. The videos of the other talks will be coming online over the next few weeks. I would recommend watching all of them!
OCMock is a powerful mock object unit testing library for Objective-C. Even if you are using Swift, as long as your classes inherit from NSObject, you can use some of its features. But what if you are writing pure Swift code which does not have access to the dynamic Objective-C runtime? Or, what if you don’t want your Swift code to be hampered by NSObject subclasses and @objc annotations? Perhaps, you merely want to avoid dependencies and use ‘plain old’ XCTest with Objective-C. It’s relatively easy and lightweight to achieve the same effect in some testing scenarios without using OCMock.
I previously wrote about writing great documentation in Swift. If you haven’t read that post, head there now to catch up. This post is a follow-up with updates for GitHub’s new way to publish docs. This is how I’ve setup all of my Swift open source projects.
As you may know, I spoke at FrenchKit a couple of months ago. The organizers have been working hard to get all of the videos edited and uploaded, and my talk is now available here. 😄
You may have noticed that I did not write the last few issues of the Swift Weekly Brief. I took some much needed time off, and I was able to unplug and relax thanks to the wonderful JP Simard and Brian Gesiak. They took over for those weeks and I can’t thank them enough! Bas Broek also made regular contributions, which was super helpful.
I recently spoke at the FrenchKit conference about Swift Evolution. The talk, 140 proposals in 30 minutes, was originally intended to be an overview of the process and each of the proposals. However, as I was writing the talk, it evolved into something much more interesting. I ended up writing some code to analyze the proposals instead.
I’m happy to share that all of my open source Swift libraries have (finally) been updated for Swift 3. If you’ve been waiting for any of these final releases, you can now run pod update or carthage update and relax — sorry it took so long! I wrote about migrating to Swift 3 a few months ago and this post shares the final results of the process that I outlined in there.
Last week I attended and gave a talk at FrenchKit in Paris, France. As expected, it was an amazing conference — especially considering it was the first FrenchKit ever. I think the organizers are already thinking about FrenchKit 2017, so keep an eye out and definitely go if you can. I know I will.
One of the most common patterns I see in software design with Objective-C (and sometimes Swift), is the use of enumeration types (enum) as configurations for a class. For example, passing an enum to a UIView to style it in a certain way. In this article, I explain why I think this is an anti-pattern and provide a more robust, modular, and extensible approach to solving this problem.
I spent most of my free time last weekend and a few days of last week on migrating my Swift code to Swift 3.0 — I migrated my open source projects as well as my private side projects. Overall, I would say my experience was “OK”. It definitely could have been better, but I think the largest problem was overcoming the cognitive hurdle of seeing all the changes and errors from Xcode’s migration tool at once. The best thing to do is wipe away the tears, put your headphones on, and start hacking. 🤓
What’s my favorite thing about Swift 3? Not maintaining third-party libraries that make Cocoa more “Swifty”. Swift 3 sherlocked my libraries, and I couldn’t be happier.
As developers, we’ve been lamenting the continued existence of the inferior A5 system-on-a-chip for the past couple of years. Both iOS 8 and iOS 9 continued to support iPhone 4S, iPad 2, and iPad Mini 1 — devices that struggled to run the OS itself. I had hoped that iOS 9 would finally drop support for these less powerful devices, but it didn’t. Today, we can finally say goodbye to the A5. Well, almost.
A few days ago I was (finally!) updating a project to use Swift 2.2 and I ran into a few issues when converting to use the new #selector syntax introduced by proposal SE-0022. If using #selector from within a protocol extension, that protocol must be declared as @objc. The former Selector("method:") syntax did not have this requirement.
I recently had an incredible experience with one of my open source projects that I’d like to share. It’s a story of openness and collaboration that I hope other open source project maintainers will find valuable. This post continues the theme of “building successful open source projects” from my previous article on documentation.
Updated: 18 Apr 2018
The Swift community is ecstatic about Swift. There are so many new libraries being released each week that some have created package indexes — even IBM. But of course, a library is only as great as its documentation.
Earlier this month I had the incredible opportunity to speak at the try! Swift conference in Tokyo, Japan. 🇯🇵 It was such a fun and rewarding experience. A video of the talk is now online over at Realm’s blog, where it is synced with my slides. If you have not already seen it, go check it out!
A few weeks ago, I spoke at Realm in San Francisco at the Swift Language User Group (#SLUG) meetup. A video of the talk is now online over at Realm’s blog, where it is synced with my slides. If you haven’t already seen it, go check it out!
Do you love writing code? Are you passionate about open source? Do you want to get more involved, but have yet to find a project to which you want contribute? Are you interested in contributing to a widely used, impactful project? Then I have a proposition for you! 😄 I am looking for dedicated core contributors to help maintain JSQMessagesViewController!
In case you are late to the party, I finally found some time to give the Swift Weekly Brief a proper home. Starting this newsletter kind of happened by accident when I first wrote about the Swift open source announcement. Since then, it was kind of bootstrapped here on my personal blog and started to feel awkward. I hacked together the new site in a couple of nights and moved all the previous posts over. Today’s issue #5 is the first one to be originally published at swiftweekly.github.io. However, there is more here than just organization and a nice separation of concerns.
Now that the holidays are over, things have started to pick up again on Swift.org. If you are following any of the repos on GitHub, you have probably noticed. I’m not sure how I missed this before, but this week I just discovered SwiftExperimental.swift. For now, it defines a bunch of custom unicode operators for Set. It’s really cool. I would love to see more APIs like this in the standard library. Anyway, here’s the weekly brief!
As expected with the holiday season, things are slowing down for a bit on Swift.org. I have been traveling for the holidays as well, so this issue will be shorter than usual. If you haven’t already, be sure you take some time away from coding to enjoy the holidays and avoid burnout. 😄 Now, the weekly brief!
The Swift.org community is finishing up its second full week of open source development. If you were hoping for a quiet week, you will definitely be disappointed. There is still a ton of activity with no signs of slowing down. The Swift team continues to work openly and to be encouraging to contributors. This week brought more crash fixes and more Swift Evolution proposals. Let’s get to it — the weekly brief!
It looks many developers in the community enjoyed my previous post detailing my thoughts and observations on the activity around the Swift open source project. So, I’m going to try to do this weekly — every Thursday, since the open source announcement was on a Thursday. Each week I’ll provide a high-level summary of what’s been happening, updates on interesting statistics, and links to interesting content. If you have any suggestions, please let me know! And now, the weekly brief!
It has only been a few days since the announcement of Swift going open source and the activity around the project has been incredible. When Apple revealed that Swift would be open source at WWDC earlier this year, I do not think anyone anticipated a release like this.
In iOS development, the core of nearly every app rests on the foundations provided by UICollectionView and UITableView. These APIs make it simple to build interfaces that display the data in our app, and allow us to easily interact with those data. Because they are so frequently used, it makes sense to optimize and refine how we use them — to reduce the boilerplate involved in setting them up, to make them testable, and more. With Swift, we have new ways with which we can approach these APIs and reimagine how we use them to build apps.
Surprisingly, I have not seen anyone talking about what I just discovered in the iOS 9.0 API Diffs. (Well, actually what Max von Webel discovered.) There’s a hidden gem in the UIKit diffs. We no longer have to suffer through tracking down obscure bugs due to non-zeroing weak references.
Recently, I came across a case (pun intended) where I needed to compare two instances of an enum type in Swift. However, it was an enum where some cases had associated values. At first glance, it is not obvious how to do this.
Updated: 23 July 2015
Mike Ash has a great Friday Q&A on namespaced constants and functions in C. It is a powerful and elegant technique to avoid using #define and verbose Objective-C prefixes. Although Swift types are namespaced by their module, we can still benefit from implementing this pattern with struct and enum types. I’ve been experimenting with this approach for constants in Swift and it has been incredibly useful.
I recently gave a talk at the Swift Language User Group (#SLUG) meetup at Realm in San Francisco. A video of the talk is now online over at Realm’s blog, where it is synced up with my slides. If you haven’t already seen it, go check it out! Realm does an absolutely amazing job with posting these meetup talks — in addition to the video and slides, there’s a full transcript and subtitles.
In a previous post, I discussed how Swift’s failable initializers could be problematic. Specifically, I argued that their ease of use could persuade or encourage us to revert to old (bad) Objective-C habits of returning nil from init. Initialization is usually not the right place to fail. We should aim to avoid optionals as much as possible to reduce having to handle this absence of values. Recently, @danielgomezrico asked a great question about a possible use case for a failable initializer — parsing JSON. Given this problem’s popularity in the Swift community, I thought sharing my response here would be helpful.
The observer pattern is a powerful way to decouple the sending and handling of events between objects in a system. On iOS, one implementation of this pattern is via NSNotificationCenter. However, the NSNotificationCenter APIs are kind of cumbersome to use and require some boilerplate code. Luckily, Swift gives us the tools to improve NSNotificationCenter with very little code.
As I continue my work with Core Data and Swift, I have been trying to find ways to make Core Data better. Among my goals are clarity and safety, specifically regarding types. Luckily, we can harness Swift’s optionals, enums, and other features to make managed objects more robust and more clear. But even with the improvements that Swift brings, there are still some drawbacks and limitations with Xcode’s current toolset.
Core Data is probably loved as much as it is shunned by iOS developers. It is a framework of great power that often comes with great frustration. But it remains a popular tool among developers despite its pitfalls — likely because Apple continues to invest in it and encourages its adoption, as well as the availability of the many open-source libraries that make Core Data easier to use. Consider unit testing, and Core Data gets a bit more cumbersome. Luckily, there are established techniques to facilitate testing your models. Add Swift to this equation, and the learning curve gets slightly steeper.
A few weeks ago I published the sixth major release of my our messages UI library for iOS. This release closes the door on a major milestone for this project, so I wanted to take the time to highlight its significance, discuss its new features, and examine its design. Of course, this would not have been possible without our amazing open-source community and the contributors to this project.
I’m incredibly happy and incredibly proud to share that Rosetta Stone is an open-source software contributor. Since I started working at Rosetta Stone a little more than a year ago, I’ve been encouraging and advocating for the company to get involved in open-source. Today, we did just that. Today is a big day for Rosetta Stone.
Swift is still young and ever-changing. With each release, we have seen dozens of tweaks, additions, and deletions. And there is no reason for us to think that this rapid evolution will decline anytime soon. To remind us of exactly that, the latest post on Apple’s Swift Developer Blog introduces a new feature in Swift 1.1 in Xcode 6.1 — failable initializers.
When the App Store launched, there was one iPhone with one screen size and one pixel density. Designing your user interfaces was relatively simple and the technical debt of hard-coding them was cheap. Today, developers and designers face many challenges in creating apps that must work on dozens of different devices. Long gone are the days of 480x320. We can no longer depend on physical screen sizes and must always be prepared for the next generation of devices.
When I find my code is slow or troubled, friends and colleagues comfort me. Speaking words of wisdom, write in C. It is understood that foregoing the features and abstractions of high-level programming languages in favor of their low-level counterparts can yield faster, more efficient code. If you abandon your favorite runtime, forget about garbage collection, eschew dynamic typing, and leave message passing behind; then you will be left with scalar operations, manual memory management, and raw pointers. However, the closer we get to the hardware, the further we get from readability, safety, and maintainability.
As Apples to apples, Part II made its way around the web, it was praised as well as critiqued. The latter largely consisted of questions regarding the real-world applications of these benchmarks. In general, benchmarks should be taken with a grain of salt. I want to take a minute to clarify my thoughts on benchmarks and how I think they can be valuable.
If at first you don’t succeed, try, try again. Practice makes perfect. These proverbs have encouraged us all in many different contexts. But in software development, they tug at our heartstrings uniquely. Programmers persevere through countless nights of fixing bugs. Companies march vigilantly toward an MVP. But after 1.0 there is no finish line, there is no bottom of the 9th inning. There are more bugs to be fixed. There are new releases ahead. The march continues, because software is not a product, it is a process.
Updated: 13 Oct 2014
You have spent countless hours, days, months, or maybe even years perfecting your app. There has been plenty of blood, sweat, and tears. Your relationships and your health have suffered through the development process. You are ready for 1.0 and the time has arrived to prepare all of your content for the App Store — app icon, keywords, description, localizations, and screenshots (and soon app previews).
Updated: 1 Aug 2014
When Craig Federighi arrived at his presentation slide about Objective-C during this year’s WWDC keynote everyone in the room seemed puzzled, curious, and maybe even a bit uneasy. What was happening? As he continued, he considered what Objective-C would be like without the C, and the room abruptly filled with rumblings and whispers [1] as developers in the audience confided in those around them. If you had been following the discussions in our community about the state of Objective-C (and why we need to replace it) during the previous months, you could only have imagined one thing: Objective-C was no more — at least not as we knew it.
XKCD’s posts on saving time and automation are precisely how this blog came to be. Until now, I never had the time or motivation to write on a regular basis, though I considered it often. I’ve been developing for iOS for a few years now and I’ve become increasingly involved in the Objective-C open-source community via GitHub and CocoaPods, and was lucky enough to attend (my first!) WWDC this year on its 25th anniversary. It was an awesome experience. With that said, I can’t think of a better time or better reason to begin writing about my experiences with iOS and Objective-C (and now Swift), as well as my involvement in open-source. I hope to share worthwhile and interesting things here.
JP and I released a special, off-schedule episode of Swift Unwrapped today. We welcomed Doug Gregor from the Swift Core Team back to the show to discuss the major new features coming in Swift 5.1.
I’m excited to share that my good friend and talented artist, Lisa Sy, and I have released a new sticker pack for iMessage! It is based on her excellent web comic, plurals and noun — a comic about queer and weird things that happen. It’s free and you can download it here.
I recently released a menu bar Mac app called Red Eye. It’s free and you can download it here. It prevents your Mac from going to sleep. Yes, it is a clone of the beloved Caffeine. And yes, it is the second menu bar app that I’ve made recently. It is notarized by Apple, so you shouldn’t have any problems installing it. I hope you enjoy it!
Continuing from my previous post, there is a bug in NSStatusItem that I forgot to mention. Thanks to Michael Tsai (tweet) for pointing out this workaround.
I just pushed a small update to Lucifer. You can download it here.
This isn’t complicated, but I found it confusing. Perhaps I am spoiled by the more modern APIs in UIKit. When writing Lucifer, a menu bar app, I wanted to have different actions for left-clicking and right-clicking on the button in the menu bar. To my surprise, this was much more cumbersome than I expected.
I made my first Mac app — Lucifer. It is a menu bar app that allows you toggle Dark Mode on and off in macOS Mojave. To be honest, it feels like a stretch to actually call this a Mac app. It is less than 100 lines of code in a single AppDelegate.swift file and the meat of the program is an AppleScript that tells System Preferences to enable or disable Dark Mode. As an iOS developer, much of the experience was familiar. The most salient aspect, however, was learning the frustrating and obscure details of app sandboxing, the “hardened runtime”, and app notarization — altogether it was like visiting hell and giving Satan a bubble bath. Appropriate, I suppose.
I tweeted a joke about estimating software engineering projects while I was at work during a team meeting for a retrospective on a project we recently shipped. The project was not completed within our original estimations. (Did I even need to say that?)
Over a weekend recently I built a tiny Mac app (more on that later). What I was trying to achieve required executing AppleScript, like so many things on macOS. It seemed simple enough, but of course new app sandboxing restrictions in macOS Mojave got in the way.
The other day I was debugging a crash in a UI test for an open pull request at work. The bug turned out to be extremely subtle and difficult to notice. I spent way too much time staring at the changes, trying to understand what was wrong. Let’s see if you can spot the error.
A common scenario in app development is to build up a list of objects, perhaps to display to the user or for another purpose. Maybe you’re fetching data from a database to display, or constructing fields to display for an interface. Consider the iOS Calendar app, for example. When you add a new calendar event, the form displays all the fields you can fill-in — title, location, date and time, notes, etc. However, when viewing an existing event all you see are the completed fields while the uncompleted fields are hidden.
One of the major changes in Swift 4.2 is a change to the calling convention. But what exactly does that mean? Why is it important and why would you want to change it?
I’ve known about the Tor Project for a long time, but I guess it’s been awhile. 😅 The last time I was actively using Tor was with Vidalia, which was apparently discontinued about 5 to 6 years ago. Ha! Whoops.
Net Neutrality is officially over in the US. As the EFF notes, it will likely manifest as a slow, painful decline of the Internet. We can call congress to demand that they reverse the decision and act in the interests of the people. But whether or not that succeeds, everyone should be using a VPN regularly now to fight against the growing threats of Internet surveillance and censorship. We know better than to trust corporations and governments.
Swift Unwrapped recorded two episodes in the Podcast studio at WWDC this year. We had Greg Heo on to talk about our reactions to the announcements from the Keynote and Platforms State of the Union. Then we discussed Swift 4.2 and beyond with Ted Kremenek.
I recently discovered a preference in Xcode’s Navigation settings that makes the ‘Assistant Editor’ much more useful, especially when writing Swift.
In a recent episode of the podcast, JP and I discussed the implicit escaping of closures in Swift. As Swift has matured and evolved, the default behavior of closure parameters in functions has changed. Prior to Swift 3, closures parameters were escaping by default. After SE-103, the default was changed to non-escaping.
I’ve removed Google Analytics from this site. I was in a similar situation as Ash Furrow, who just wrote about doing this. I’m removing it because it simply causes more harm than good.
I just updated my blog to use Bootstrap 4.1 from v3.3.7. Its a major version with lots of breaking changes, so it took me a few hours over a few Saturday afternoons to get everything fixed up. That’s also partially why I missed posting something last month.
I’m not interested in being an advertising product for Google to exploit. I’m also not interested in the company’s unsavory practices, in general. I’ve been using DuckDuckGo for over a year now, and I’m incredibly happy with it as a replacement for Google Search — not only for personal usage, but also for implementing a custom search component for this site.
Updated: 05 Jan 2019
When you file a radar for a bug on one of Apple’s platforms, you should (usually) always attach a sysdiagnose. A sysdiagnose provides a lot of helpful information for the person who is trying to understand how the bug happened. Amongst other things, it contains logs from various parts of the OS, and all recent crash logs. Without it, the person on the other end of your report inside Apple may not be of much help. On macOS running sysdiagnose is somewhat common, but what about iOS?
Updated: 08 Feb 2018
Next week’s issue of Swift Weekly Brief will be its 100th and final issue. I started this newsletter a little over two years ago, covering the initial open sourcing of Swift, the 3.0 release, the 4.0 release, and many significant milestones in-between for the language and the community. With few exceptions, there was a new issue every week thanks to the other amazing writers and contributors. The newsletter quickly became an important resource for the Swift community. Because of this, I’m sure many of you will be saddened to hear that the 100th issue will be the last. At least, Issue #100 will be the last issue for me, for now — but if someone from the community is willing to take over this project, it can continue.
Updated: 18 Apr 2018
Epsilon. ε. The fifth letter of the Greek alphabet. In calculus, an arbitrarily small positive quantity. In formal language theory, the empty string. In the theory of computation, the empty transition of an automaton. In the ISO C Standard, 1.19e-07 for single precision and 2.22e-16 for double precision.
The other day I was attempting to use FLT_EPSILON (which I later learned was laughably incorrect) when the Swift 4 compiler emitted a warning saying that FLT_EPSILON is deprecated and to use .ulpOfOne instead. What the hell is ulpOfOne? I read the documentation and then everything made sense — ha, just kidding. The FloatingPoint.ulpOfOne docs generously describe the static variable as the unit in the last place of 1.0 — whatever that means. Let’s find out.
PlanGrid is a productivity app for construction fieldworkers. The easiest way to explain it to software developers is that it’s like an IDE, Git, and GitHub or JIRA — but for construction. Think of all the amazing software tools we have to do our jobs as programmers. The equivalent tools for construction simply did not exist before PlanGrid, and they still have a lot of room to grow.
As software developers, we build software for specific purposes. We anticipate that people will use an app in certain ways. Yet, we often discover that users are behaving differently than we expected. They hack a custom, “unsupported” workflow to workaround an app’s unintended limitations. Once we realize this, we have the power to turn these user workarounds into first-class features. However, sometimes we find that our apps are being used in totally different, unimaginable ways.
At PlanGrid, we recently discovered that the app was being used as a digital archaeological tool.
The Swift type-checker remains a performance bottleneck for compile times, though it has improved tremendously over the past two years. You could even say the type-checker has gone from being drunk to sober. To help users debug these issues, awhile back Jordan Rose added a frontend Swift compiler flag that would emit warnings in Xcode for functions that took too long to compile, or rather took too long to type-check. In Xcode 9, there’s a new, similar flag for checking expressions.
This site used to be hosted via GitHub Pages, but I decided to move to a dedicated host to have more control over how I develop and deploy the site, and how it’s configured. A number of limitations and quirks eventually drove me to migrate away from GitHub pages to my excellent and inexpensive bare-bones host, NearlyFreeSpeech.net. I was also interested in learning to do all of this on my own, rather than relying on GitHub Pages “magic”. If you’re looking to setup your own Jekyll-powered site, or if you’re looking to migrate off of GitHub Pages, hopefully this is helpful.
The Swift community has been through some rough migrations. It is frustrating when your project no longer compiles because of API and syntax changes, but it is an entirely different story when your project seg faults the compiler. When that happens, you cannot simply run a migration tool or apply fix-its — your project is broken and there’s little you can do until a fix is released. This is why the swift-source-compat-suite project was created.
Updated: 18 July 2017
Beginning immediately, JSQMessagesViewController is no longer officially supported or maintained. In fact, you may have noticed that it has been neglected for the past year. The most recent release was published almost exactly one year ago today. This is an incredibly difficult post for me to write and I have not made this decision carelessly. This open source project had a great run. There was (and still is) a great community around it, and I’m sorry for bringing this to an end.
Protocols in Swift and Objective-C are a powerful tool to decouple your code. They allow you to specify a contract between classes that consume them, but defer a concrete implementation to conformers. They allow you to segregate interfaces and invert control. One interesting aspect of protocols in Swift and Objective-C is that protocol members can be optional (optional in Swift or @optional in Objective-C). Unfortunately, this comes with a number of disadvantages and diminishes the robustness of your code, so it is often avoided. However, having optional members is sometimes the right conceptual model for your design. How can you design your protocols to provide optional semantics without specifying them as optional or @optional?
In a previous post I discussed strategies for using singletons in a cleaner, more modular way. Singletons are a fact of software development, especially in iOS. Sometimes the design pattern actually is the right tool for the job. In those situations, how we can improve the way we write our own singleton classes?
There has been a ton of debate on the swift-evolution mailing lists about access control in Swift. A couple of days ago, the proposal SE-0159: Fix Private Access Levels was rejected. I want to share my thoughts on this, as well as thoughts on the larger story for access control in general. But first, let’s begin with a brief history of access control in Swift.
A few months back, JP Simard and I decided to start a podcast about Swift — the language itself, its evolution and development, the Swift.org open source projects, and general Swifty news. There are a ton of great podcasts out there about developing for Apple platforms and Apple news, but there’s nothing exclusively about Swift the language. In many ways, this podcast is an extension of and commentary on the Swift Weekly Brief newsletter. However, we’ll be doing deep dives on various topics and elaborating on concepts in greater detail. I’m excited to share that we launched Swift Unwrapped yesterday with Spec.fm!
In my previous post I mentioned writing adaptive code. That is to say, writing code that is easy to change, code that is malleable. It’s like creating adaptive user interfaces but for all of your classes, modules, and other components.
In software development, singletons are widely discouraged and frowned upon — but with good reason. They are difficult or impossible to test, and they entangle your codebase when used implicitly in other classes, making code reuse difficult. Most of the time, a singleton amounts to nothing more than a disguise for global, mutable state. Everyone knows at least knows that is a terrible idea. However, singletons are occasionally an unavoidable and necessary evil. How can we incorporate them into our code in a clean, modular, and testable way?
A few months ago, I spoke at Swift Summit in San Francisco. The conference has a reputation for providing high-quality talks, and this year was no different. Fortunately, I was able to see nearly all of the talks and not a single one disappointed me. It was such a great conference. The video and full transcript of my talk are now available. The videos of the other talks will be coming online over the next few weeks. I would recommend watching all of them!
OCMock is a powerful mock object unit testing library for Objective-C. Even if you are using Swift, as long as your classes inherit from NSObject, you can use some of its features. But what if you are writing pure Swift code which does not have access to the dynamic Objective-C runtime? Or, what if you don’t want your Swift code to be hampered by NSObject subclasses and @objc annotations? Perhaps, you merely want to avoid dependencies and use ‘plain old’ XCTest with Objective-C. It’s relatively easy and lightweight to achieve the same effect in some testing scenarios without using OCMock.
I previously wrote about writing great documentation in Swift. If you haven’t read that post, head there now to catch up. This post is a follow-up with updates for GitHub’s new way to publish docs. This is how I’ve setup all of my Swift open source projects.
As you may know, I spoke at FrenchKit a couple of months ago. The organizers have been working hard to get all of the videos edited and uploaded, and my talk is now available here. 😄
You may have noticed that I did not write the last few issues of the Swift Weekly Brief. I took some much needed time off, and I was able to unplug and relax thanks to the wonderful JP Simard and Brian Gesiak. They took over for those weeks and I can’t thank them enough! Bas Broek also made regular contributions, which was super helpful.
I recently spoke at the FrenchKit conference about Swift Evolution. The talk, 140 proposals in 30 minutes, was originally intended to be an overview of the process and each of the proposals. However, as I was writing the talk, it evolved into something much more interesting. I ended up writing some code to analyze the proposals instead.
I’m happy to share that all of my open source Swift libraries have (finally) been updated for Swift 3. If you’ve been waiting for any of these final releases, you can now run pod update or carthage update and relax — sorry it took so long! I wrote about migrating to Swift 3 a few months ago and this post shares the final results of the process that I outlined in there.
Last week I attended and gave a talk at FrenchKit in Paris, France. As expected, it was an amazing conference — especially considering it was the first FrenchKit ever. I think the organizers are already thinking about FrenchKit 2017, so keep an eye out and definitely go if you can. I know I will.
One of the most common patterns I see in software design with Objective-C (and sometimes Swift), is the use of enumeration types (enum) as configurations for a class. For example, passing an enum to a UIView to style it in a certain way. In this article, I explain why I think this is an anti-pattern and provide a more robust, modular, and extensible approach to solving this problem.
I spent most of my free time last weekend and a few days of last week on migrating my Swift code to Swift 3.0 — I migrated my open source projects as well as my private side projects. Overall, I would say my experience was “OK”. It definitely could have been better, but I think the largest problem was overcoming the cognitive hurdle of seeing all the changes and errors from Xcode’s migration tool at once. The best thing to do is wipe away the tears, put your headphones on, and start hacking. 🤓
What’s my favorite thing about Swift 3? Not maintaining third-party libraries that make Cocoa more “Swifty”. Swift 3 sherlocked my libraries, and I couldn’t be happier.
As developers, we’ve been lamenting the continued existence of the inferior A5 system-on-a-chip for the past couple of years. Both iOS 8 and iOS 9 continued to support iPhone 4S, iPad 2, and iPad Mini 1 — devices that struggled to run the OS itself. I had hoped that iOS 9 would finally drop support for these less powerful devices, but it didn’t. Today, we can finally say goodbye to the A5. Well, almost.
A few days ago I was (finally!) updating a project to use Swift 2.2 and I ran into a few issues when converting to use the new #selector syntax introduced by proposal SE-0022. If using #selector from within a protocol extension, that protocol must be declared as @objc. The former Selector("method:") syntax did not have this requirement.
I recently had an incredible experience with one of my open source projects that I’d like to share. It’s a story of openness and collaboration that I hope other open source project maintainers will find valuable. This post continues the theme of “building successful open source projects” from my previous article on documentation.
Updated: 18 Apr 2018
The Swift community is ecstatic about Swift. There are so many new libraries being released each week that some have created package indexes — even IBM. But of course, a library is only as great as its documentation.
Earlier this month I had the incredible opportunity to speak at the try! Swift conference in Tokyo, Japan. 🇯🇵 It was such a fun and rewarding experience. A video of the talk is now online over at Realm’s blog, where it is synced with my slides. If you have not already seen it, go check it out!
A few weeks ago, I spoke at Realm in San Francisco at the Swift Language User Group (#SLUG) meetup. A video of the talk is now online over at Realm’s blog, where it is synced with my slides. If you haven’t already seen it, go check it out!
Do you love writing code? Are you passionate about open source? Do you want to get more involved, but have yet to find a project to which you want contribute? Are you interested in contributing to a widely used, impactful project? Then I have a proposition for you! 😄 I am looking for dedicated core contributors to help maintain JSQMessagesViewController!
In case you are late to the party, I finally found some time to give the Swift Weekly Brief a proper home. Starting this newsletter kind of happened by accident when I first wrote about the Swift open source announcement. Since then, it was kind of bootstrapped here on my personal blog and started to feel awkward. I hacked together the new site in a couple of nights and moved all the previous posts over. Today’s issue #5 is the first one to be originally published at swiftweekly.github.io. However, there is more here than just organization and a nice separation of concerns.
Now that the holidays are over, things have started to pick up again on Swift.org. If you are following any of the repos on GitHub, you have probably noticed. I’m not sure how I missed this before, but this week I just discovered SwiftExperimental.swift. For now, it defines a bunch of custom unicode operators for Set. It’s really cool. I would love to see more APIs like this in the standard library. Anyway, here’s the weekly brief!
As expected with the holiday season, things are slowing down for a bit on Swift.org. I have been traveling for the holidays as well, so this issue will be shorter than usual. If you haven’t already, be sure you take some time away from coding to enjoy the holidays and avoid burnout. 😄 Now, the weekly brief!
The Swift.org community is finishing up its second full week of open source development. If you were hoping for a quiet week, you will definitely be disappointed. There is still a ton of activity with no signs of slowing down. The Swift team continues to work openly and to be encouraging to contributors. This week brought more crash fixes and more Swift Evolution proposals. Let’s get to it — the weekly brief!
It looks many developers in the community enjoyed my previous post detailing my thoughts and observations on the activity around the Swift open source project. So, I’m going to try to do this weekly — every Thursday, since the open source announcement was on a Thursday. Each week I’ll provide a high-level summary of what’s been happening, updates on interesting statistics, and links to interesting content. If you have any suggestions, please let me know! And now, the weekly brief!
It has only been a few days since the announcement of Swift going open source and the activity around the project has been incredible. When Apple revealed that Swift would be open source at WWDC earlier this year, I do not think anyone anticipated a release like this.
In iOS development, the core of nearly every app rests on the foundations provided by UICollectionView and UITableView. These APIs make it simple to build interfaces that display the data in our app, and allow us to easily interact with those data. Because they are so frequently used, it makes sense to optimize and refine how we use them — to reduce the boilerplate involved in setting them up, to make them testable, and more. With Swift, we have new ways with which we can approach these APIs and reimagine how we use them to build apps.
Surprisingly, I have not seen anyone talking about what I just discovered in the iOS 9.0 API Diffs. (Well, actually what Max von Webel discovered.) There’s a hidden gem in the UIKit diffs. We no longer have to suffer through tracking down obscure bugs due to non-zeroing weak references.
Recently, I came across a case (pun intended) where I needed to compare two instances of an enum type in Swift. However, it was an enum where some cases had associated values. At first glance, it is not obvious how to do this.
Updated: 23 July 2015
Mike Ash has a great Friday Q&A on namespaced constants and functions in C. It is a powerful and elegant technique to avoid using #define and verbose Objective-C prefixes. Although Swift types are namespaced by their module, we can still benefit from implementing this pattern with struct and enum types. I’ve been experimenting with this approach for constants in Swift and it has been incredibly useful.
I recently gave a talk at the Swift Language User Group (#SLUG) meetup at Realm in San Francisco. A video of the talk is now online over at Realm’s blog, where it is synced up with my slides. If you haven’t already seen it, go check it out! Realm does an absolutely amazing job with posting these meetup talks — in addition to the video and slides, there’s a full transcript and subtitles.
In a previous post, I discussed how Swift’s failable initializers could be problematic. Specifically, I argued that their ease of use could persuade or encourage us to revert to old (bad) Objective-C habits of returning nil from init. Initialization is usually not the right place to fail. We should aim to avoid optionals as much as possible to reduce having to handle this absence of values. Recently, @danielgomezrico asked a great question about a possible use case for a failable initializer — parsing JSON. Given this problem’s popularity in the Swift community, I thought sharing my response here would be helpful.
The observer pattern is a powerful way to decouple the sending and handling of events between objects in a system. On iOS, one implementation of this pattern is via NSNotificationCenter. However, the NSNotificationCenter APIs are kind of cumbersome to use and require some boilerplate code. Luckily, Swift gives us the tools to improve NSNotificationCenter with very little code.
As I continue my work with Core Data and Swift, I have been trying to find ways to make Core Data better. Among my goals are clarity and safety, specifically regarding types. Luckily, we can harness Swift’s optionals, enums, and other features to make managed objects more robust and more clear. But even with the improvements that Swift brings, there are still some drawbacks and limitations with Xcode’s current toolset.
Core Data is probably loved as much as it is shunned by iOS developers. It is a framework of great power that often comes with great frustration. But it remains a popular tool among developers despite its pitfalls — likely because Apple continues to invest in it and encourages its adoption, as well as the availability of the many open-source libraries that make Core Data easier to use. Consider unit testing, and Core Data gets a bit more cumbersome. Luckily, there are established techniques to facilitate testing your models. Add Swift to this equation, and the learning curve gets slightly steeper.
A few weeks ago I published the sixth major release of my our messages UI library for iOS. This release closes the door on a major milestone for this project, so I wanted to take the time to highlight its significance, discuss its new features, and examine its design. Of course, this would not have been possible without our amazing open-source community and the contributors to this project.
I’m incredibly happy and incredibly proud to share that Rosetta Stone is an open-source software contributor. Since I started working at Rosetta Stone a little more than a year ago, I’ve been encouraging and advocating for the company to get involved in open-source. Today, we did just that. Today is a big day for Rosetta Stone.
Swift is still young and ever-changing. With each release, we have seen dozens of tweaks, additions, and deletions. And there is no reason for us to think that this rapid evolution will decline anytime soon. To remind us of exactly that, the latest post on Apple’s Swift Developer Blog introduces a new feature in Swift 1.1 in Xcode 6.1 — failable initializers.
When the App Store launched, there was one iPhone with one screen size and one pixel density. Designing your user interfaces was relatively simple and the technical debt of hard-coding them was cheap. Today, developers and designers face many challenges in creating apps that must work on dozens of different devices. Long gone are the days of 480x320. We can no longer depend on physical screen sizes and must always be prepared for the next generation of devices.
When I find my code is slow or troubled, friends and colleagues comfort me. Speaking words of wisdom, write in C. It is understood that foregoing the features and abstractions of high-level programming languages in favor of their low-level counterparts can yield faster, more efficient code. If you abandon your favorite runtime, forget about garbage collection, eschew dynamic typing, and leave message passing behind; then you will be left with scalar operations, manual memory management, and raw pointers. However, the closer we get to the hardware, the further we get from readability, safety, and maintainability.
As Apples to apples, Part II made its way around the web, it was praised as well as critiqued. The latter largely consisted of questions regarding the real-world applications of these benchmarks. In general, benchmarks should be taken with a grain of salt. I want to take a minute to clarify my thoughts on benchmarks and how I think they can be valuable.
If at first you don’t succeed, try, try again. Practice makes perfect. These proverbs have encouraged us all in many different contexts. But in software development, they tug at our heartstrings uniquely. Programmers persevere through countless nights of fixing bugs. Companies march vigilantly toward an MVP. But after 1.0 there is no finish line, there is no bottom of the 9th inning. There are more bugs to be fixed. There are new releases ahead. The march continues, because software is not a product, it is a process.
Updated: 13 Oct 2014
You have spent countless hours, days, months, or maybe even years perfecting your app. There has been plenty of blood, sweat, and tears. Your relationships and your health have suffered through the development process. You are ready for 1.0 and the time has arrived to prepare all of your content for the App Store — app icon, keywords, description, localizations, and screenshots (and soon app previews).
Updated: 1 Aug 2014
When Craig Federighi arrived at his presentation slide about Objective-C during this year’s WWDC keynote everyone in the room seemed puzzled, curious, and maybe even a bit uneasy. What was happening? As he continued, he considered what Objective-C would be like without the C, and the room abruptly filled with rumblings and whispers [1] as developers in the audience confided in those around them. If you had been following the discussions in our community about the state of Objective-C (and why we need to replace it) during the previous months, you could only have imagined one thing: Objective-C was no more — at least not as we knew it.
XKCD’s posts on saving time and automation are precisely how this blog came to be. Until now, I never had the time or motivation to write on a regular basis, though I considered it often. I’ve been developing for iOS for a few years now and I’ve become increasingly involved in the Objective-C open-source community via GitHub and CocoaPods, and was lucky enough to attend (my first!) WWDC this year on its 25th anniversary. It was an awesome experience. With that said, I can’t think of a better time or better reason to begin writing about my experiences with iOS and Objective-C (and now Swift), as well as my involvement in open-source. I hope to share worthwhile and interesting things here.
I’ve been eating vegetarian (and often vegan) for a decade now. I don’t talk about it much. This is a choice I’ve made for myself and my own reasons. What I never imagined happening is the growing popularity and wide availability of vegan/vegetarian food. It is simply remarkable.
I deleted my LinkedIn account, well sort of. I kept my account open, which I will explain below, but I left it mostly empty. You could say I am now officially linked out.
I tweeted a joke about estimating software engineering projects while I was at work during a team meeting for a retrospective on a project we recently shipped. The project was not completed within our original estimations. (Did I even need to say that?)
There’s a place called North Berkeley Frame in downtown Berkeley on Shattuck. It’s a framing shop and gallery (sort of) run by this guy named Lars. He’s older, probably mid-fifties or early sixties. He has gray hair, a gray beard, and a gentle face. I’ve had him frame some prints and other artwork for me. He’s always helpful in choosing the right frame, and his work is excellent. Like many older folks I know, he loves to talk.
Fifteen years ago today my sister died. Most people don’t know about her — Amy. I don’t talk about her much, because talking about death makes people uncomfortable, especially when the loss was so traumatic for those left behind. I was 14, she was 16. It feels like it happened a lifetime ago and that it just happened yesterday, all at once.
I haven’t read the book, The Four Agreements, but I will eventually. However, simply knowing what the Four Agreements are has been tremendously helpful for me. They may help you, too. I want to write them down to share, but also to remember them better and have a reference to revisit in the future.
The mayor of San Francisco called out feces on the sidewalks as a core problem to address in the city and wants homeless folks to “at least have respect” and “clean up after themselves”. It’s an unfortunate response, but I’m sure a lot of folks agree with the sentiment. No one relishes walking through the dirty streets in this city and it certainly is a concern, but this kind of rhetoric is actively harmful. It deliberately shifts responsibility for the problem onto the victims and away from the system that produced it. Homeless folks are among the most vulnerable in our society. In addition to their lack of housing, persistent precarity, mental health issues, and emotional struggles, the city is now going to ask them for respect and cleanliness?
I had a great time at WWDC this year, meeting new friends and catching up with old ones. Those experiences are the ones that matter the most to me. The newly announced tech is interesting and fun, but ultimately fleeting and ephemeral.
I’ve removed Google Analytics from this site. I was in a similar situation as Ash Furrow, who just wrote about doing this. I’m removing it because it simply causes more harm than good.
PlanGrid is a productivity app for construction fieldworkers. The easiest way to explain it to software developers is that it’s like an IDE, Git, and GitHub or JIRA — but for construction. Think of all the amazing software tools we have to do our jobs as programmers. The equivalent tools for construction simply did not exist before PlanGrid, and they still have a lot of room to grow.
As software developers, we build software for specific purposes. We anticipate that people will use an app in certain ways. Yet, we often discover that users are behaving differently than we expected. They hack a custom, “unsupported” workflow to workaround an app’s unintended limitations. Once we realize this, we have the power to turn these user workarounds into first-class features. However, sometimes we find that our apps are being used in totally different, unimaginable ways.
At PlanGrid, we recently discovered that the app was being used as a digital archaeological tool.
Earlier this week, the Tech Workers Coalition and UNITE HERE! in San Francisco hosted a panel discussion on how we can use our power as consumers to support hotel workers in the Bay Area and across the United States. The tech industry is full of remote workers, as well as conference organizers that host thousands of conferences each year — meaning thousands of programmers, designers, product managers, and others travel all the time to attend these conferences or attend their own company’s events. By choosing to stay at a fair hotel, you can make a significant impact on an industry where workers are struggling to negotiate fair wages and benefits.
There has been a ton of debate on the swift-evolution mailing lists about access control in Swift. A couple of days ago, the proposal SE-0159: Fix Private Access Levels was rejected. I want to share my thoughts on this, as well as thoughts on the larger story for access control in general. But first, let’s begin with a brief history of access control in Swift.
In my previous post I mentioned writing adaptive code. That is to say, writing code that is easy to change, code that is malleable. It’s like creating adaptive user interfaces but for all of your classes, modules, and other components.
Today I found out that I’m part of a class action lawsuit against a service that I never signed up for called TalentBin. As you have likely experienced, most recruiting in the tech industry is debase, disingenuous, boilerplate garbage. But this — this is definitely a new a low.
Let me list the ways that burnout happens in this industry, and especially in open source. No, I don’t need to. Because you know them already. I’m not burnt out, I promise. I’m reprioritizing, just letting you know.
A friend recently sent me The short instructional manifesto for relationship anarchy by Andie Nordgren. It is short and a good primer on relationship anarchy if you are not familiar. Take a look.
I intend to start a new series of posts called Reading Notes where I publish notes, excerpts, and thoughts on what I’m currently reading. My goals are to better document my notes and thoughts on what I’m reading for my future self, and give myself a reason to write more blog posts (in general, but also more non-technical ones). I also hope to inspire you, dear reader, to read some of these books and essays.
Here’s the list of the books I read in 2018. There are 36 in total. At first it seemed like a small number to me. However, that averages to three books per month, which actually feels like a lot. In fact, I’m not sure I could read more than three books each month. There was never a time last year when I wasn’t reading something, and I often read multiple books at once.
I finished reading Chimamanda Ngozi Adichie’s new book, Dear Ijeawele, or a Feminist Manifesto in Fifteen Suggestions. You should read it. As well as We Should All Be Feminists while you’re at it.
Data & Society recently released a stunning report, Media Manipulation and Disinformation Online. I highly suggest you read it if you care about understanding the rise of neo-fascism, the ‘fake news’ phenomenon, and manipulation of the media that plagued the 2016 US Presidential Election — and how Silicon Valley, particularly social media platforms, facilitated the rise of the alt-right movement and the spread of fascist propaganda. Don’t let the more than 100 pages deter you. The core report is only 50 pages, followed by a few pages of case studies, and finally a whopping 45 pages of citations and bibliography. (Direct download)