Tech Blog

Marius Constantinescu

MobOS conference journal

February 16, 2019

I’m sitting in the domestic departures terminal of the Cluj Airport. Used to the traffic in Bucharest, I left as soon as the workshop ended, hoping to catch my flight. I was surprised to be in front of my departure gate 30 minutes after I left the workshop. Now I hope I can also finish a blogpost before I board the plane.

Leaving in a hurry also meant I missed the final group photo of the conference. Not that I’m too photogenic or attention-seeking, but that’s a group I was happy to be a part of.

My highlights of this conference, as an iOS developer, were the talks by Andrea Cipriani, Paul Hudson and Ellen Shapiro, and Jorge Ortiz’s workshop. I didn’t know Andrea before, but Esteban warned me, and I was super impressed by his talk. Fast pace, very clear, straight to the point, all while keeping the audience interested and connected. Paul Hudson was no surprise, I saw him before, he’s probably the most entertaining speaker that the iOS community has, and he delivered again. I’ve never seen Ellen talk before, but I’ve known about her for a while. I really enjoyed her talk, which made complex things seem easy. And Jorge is probably one of the best persons to have in a workshop. 👍

Another major highlight for me was meeting some of the best people of the iOS dev community in Cluj. And I include here the people who took care of organizing the conference. I was really impressed by what they do, and I can honestly say they’re great people. I’ve never seen more attention to details and care for the speakers at any other conference. Hats off to them 🙇‍♂️.

As always, the best track of any conference was the hallway track. I don’t know if that’s valid for everyone, you need to know how to take advantage of the hallway track. There are some great resources out there, that I don’t really have the time to search for now and link here (got to finish this before my plane boards, right? 😅).

I had great interactions during those days with, among others, Dave Verwer, Jorge Ortiz, Dorin Danciu, Bogdan Iusco, David Hart and two great and friendly developer from Croatia who I was happy to give a crash course in the Romanian language. People I’d be very happy to meet again at other events.

MobOS is at its sixth edition. It’s been growing constantly, and it’s getting better and bigger each year. It’s not officially announced, but I know the organizers are already thinking about the next edition. I’d be happy to be able to join again, and I totally advise anyone to keep an eye out for their announcements. You can follow them on Twitter.

Diversity is something I’ve been thinking a lot about lately. A quick look over the mobOS speakers list will probably make people say the lineup is not too diverse. I had the same thought, and that’s a feedback I also gave them. Moreover, I offered to help improve this in the next years. They were very receptive and I’m already looking forward to the future.

We want diversity in the speaker lineup to encourage diversity for the attendees. This year, MobOS had by far the most diverse and inclusive list of participants I’ve ever seen.

Writing is hard. And I noticed that sometimes my ideas aren’t too organized. So for this blogpost I chose to follow a style I first saw at Brent Simmon and which, on this moment, suited me better. Hoping I’ll be able to publish this before I board my plane.

Making iOS Goodies

September 30, 2018

It’s been a bit over one year since I’ve been sending iOS Goodies constantly, every week, to our subscribers. It’s been a good year, both rewarding and challenging, with ups and downs.

The beginnings

My first contribution to iOS Goodies was in May 2015, fixing a wrong link. I can’t remember exactly how I found out about the newsletter, but I think that I was following Rui Peres, one of its founders, on Twitter. And what I really loved about it was the fact that it was open source, and everyone had the opportunity to contribute to it.

Since that first commit, I started contributing more often. Initially only with a few articles, then with more. Whenever I found an iOS article that I found interesting, I submitted it to iOS Goodies, for everyone else to read it. I like to keep up to date with the most recent articles in the iOS dev world, which means I read a lot of them. So contributing to iOS Goodies was more about sharing with the others what I found, instead of a goal in itself. I didn’t look for articles for iOS Goodies, I read iOS dev articles and when I liked them, I submitted them to the newsletter.

Initially, the process of submitting an article was a bit cumbersome. You had to fork the GitHub repo, edit your fork, and make a pull request. This is the normal way of working on open source projects on GitHub. However, for submitting an article for a newsletter, I thought it was a bit annoying. But at some point (can’t remember when) I discovered GitHub added the possibility to edit a file on a repo in the browser, and if you didn’t have write access to that repo, it would open a pull request. I can’t remember if this was a new feature or if it was new only for me, but this made it so much easier for me to contribute to the newsletter.

One of the problems that I would run into when contributing to iOS Goodies was that if the PRs weren’t reviewed fast enough and other people also submitted articles, our PRs would get into a conflict. One PR would get merged, the other would have to be rebased. This was less than ideal. But about one year later, probably due to the fact that I contributed a lot to the repo, I was granted access to the repo, so I didn’t have to submit PRs anymore. Instead, I could edit the current issue directly, and I could also help merge the other PRs faster, to minimize the number of merge conflicts. Currently, with GitHub’s new feature of fixing merge conflicts in the web editor, I’m fixing the conflicts myself before merging other people’s PRs. I think the most common practice for an open source project is for the one who opened the PR to fix the conflicts, but in our case, I want it to be as easy as possible for everyone to contribute. This means that if they submitted an article via a PR, I wouldn’t want to ask them to rebase, so I just do that myself in the web editor.

Chef Marius Constantinescu cooked your goodies

Last year, after a period where Tiago and Rui were very busy, they asked me if I want to take over it. I thought about it and I decided I wanted to give it a try. One year later, I’m still sending it :). Of course, this is only possible with the help from our community. We have a few constant contributors, some of them have write access to the repo and can review and merge other contributor’s suggestions. So even though I’m sending the newsletter and writing the initial comment, this is a team effort, and I’m very thankful to all our contributors and maintainers.

How I choose what goes in

One thing I know people are wondering a lot is how I choose what goes in the newsletter and what doesn’t. First of all, the article has to be of good quality to get into the newsletter. It happened (very rarely, though) that I decided not to publish an article because I thought it wasn’t good enough. The more often case is when we have too many articles submitted, and we only have to choose 5 (but in those cases, I usually allow 6 or 7).

Regarding the criteria for what makes it in the newsletter, I usually like to give priority to the “less famous” authors. However, that’s not a strict rule, if someone who already has a large following on Twitter writes a great article, I will still include it. In the end, there’s a little bit of subjectivity from my side too. I will, of course, be tempted to share what I find interesting and relevant. Other people may find other articles more relevant. So there will always be a bit of subjectivity to iOS Goodies, which I can’t really do anything about. We brand as a community newsletter, but it’s borderline, as I’m the one selecting what actually goes in the newsletter. Yes, anyone can contribute. And yes, there are editions where most of the links are sent by other contributors. But I’m the one writing the initial comment, and I’m the one that in the end decides what goes in and what not. So I can understand why some people could have problems calling iOS Goodies a community newsletter. It’s something I think about quite a lot.

I started as a contributor, I added whatever links I found interesting. Now there are weeks where I also find other interesting articles that weren’t submitted by our contributors yet. It’s very complicated to choose what goes in. Should I add the links I find interesting, even if that means we’ll end up with too many and I’ll have to ignore some of the ones submitted by other people? Are we still a community newsletter if I do that? It’s much more complicated than it seems, keeping a community around the newsletter, choosing the best articles, promoting new voices, not discouraging new contributors by rejecting their proposals…

Time spent

It depends a lot on what you count as “iOS Goodies time”. I’m an iOS developer, I read iOS development articles and news and I keep up to date with the latest trends. That probably takes me around 1.5 hours per day, maybe even more. I usually do that while using public transport, but sometimes also in the morning before work or in the evenings, after work. I don’t usually do it on the weekends, though, because I also want to have some time to spend with family and friends. Merging PRs, replying to emails and messages, that could also take around 1 hour per week. Luckily, with merging PRs, Rui Barbosa helps a lot. And unfortunately, replying to emails and messages is something I need to get better at. Currently, my response times are a bit too long. Actually choosing what goes in the newsletter, writing the intro, creating the new post on the website and sending out the campaign, that could also take 1-2 hours every Thursday.

Sponsorships

We have taken some sponsorships every now and then, only to keep the newsletter sustainable. I don’t take sponsorships just to make money for iOS Goodies. I’m trying to keep this as ad-free as possible, without having to pay for the newsletter’s maintenance costs myself. And by maintenance costs, I mean hosting, MailerLite subscription, etc. The iOS Goodies team isn’t paid to send out the newsletter every week. I don’t reach out to sponsors, they’ve always been the ones who contacted me, and I’ve turned most of them down. We only take sponsorships very rarely, from sponsors we know and we trust, and which we think can have interesting messages for our readers.

I’ve also tried something different a few times: we had a partnership with Swift Island, where we were community partners of the conference, promoting each other. And we also tried with ADDC to give a free ticket to a lucky subscriber. I hope those experiments were well received.

Regrets / mistakes

One of the things I’m sure I could’ve done better is how I handled the GDPR stuff. I didn’t realise it would affect iOS Goodies until very late, and when I did I followed MailerLite’s suggestions on this topic and sent out an email to our subscribers, asking them to reconfirm their subscription. We lost more than half of our subscribers at that point.

Difficulties

The hardest categories are the business and design. And mostly design. There’s a lot of “15 trends for this summer”, “5 ways to make your app pop”, etc. I’m seriously wondering if I should strive to find UX/UI links or just have one link in the weeks where I find a really good one. That’s actually one of the big questions I’m having: should I add articles in a category even if I didn’t find good ones that week? It could be that I just don’t know where to find good design resources for developers. But judging by the limited number of good design/business articles in other iOS dev newsletters, I’m thinking it’s more of a general problem.

Statistics

We pride on being an open source newsletter, but so far we weren’t too open about the number of subscribers. I can’t really say I know the reason for that. Anyway, here goes… We were at around 4300 subscribers before GDPR, then after asking them to reconfirm their subscription we were left with a bit less than 1600. Now we’re almost 2000 and growing.

However, I don’t think it’s the number of subscribers that make a newsletter great, it’s the quality of the content. And I think we’re doing pretty well there. Of course, I’d like to have more subscribers, because I think we do a pretty good job and we could help more people find great iOS dev articles. I’ve often seen cases where an article or library that we shared is picked one or two weeks later by one of the bigger newsletters, and then a lot of people I follow on Twitter find out about it for the first time. I get a weird mix of feelings of satisfaction, knowing that I helped spread the word about that, but also a bit of annoyance, because iOS Goodies shared it 2 weeks before, and people only find out about it now.

But one of the things I’m most proud of is that we didn’t miss a single edition this whole year. That was one of my main focuses and goals, to get iOS Goodies back to a regular schedule. And I’m happy to say we did that :)

Getting feedback

Getting feedback is awesome. There are periods of weeks, even months, where I just send out the newsletter and that’s it. No feedback, no comment. I sometimes make changes (like writing a few words before the links in every email or adding the tool’s short description). I got a few messages from people that were happy with the new approach. That is awesome and it “validates” my ideas. I’d like to get more feedback, both good and bad. On the other hand, getting too much feedback would probably be overwhelming, and then iOS Goodies would need even more time from my side.

Other newsletters

I like to keep up with the trends in what I do, so I subscribe to other newsletters too. Of course, iOS Dev Weekly (for which I even wrote an issue 1.5 years ago), I’m subscribed to Ray Wenderlich’s newsletter, I used to be subscribed to NatashaTheRobot’s newsletter (but that’s stopped now), and I follow Indie iOS Focus, Swift Developments, Swift Weekly Brief and Awesome iOS.

Future plans

For the future, I’m hoping to be able to keep sending out the newsletter every week. The process is time-consuming, and it would be nice if I could automate it a bit. I’ve been looking at Swift Weekly Brief, they have a very nice workflow for sending out the newsletter and publishing an article each week. Adopting something like that for iOS Goodies would be quite a big change, and I’m still considering if that’s something I’d like to implement or not.

Another thing I’ll probably do before the end of this year is to remove Google Analytics form our website. Currently, we use Google Analytics. However, I’ve discovered I only looked at the statistics twice. I don’t really need them, and that’s why I don’t really feel comfortable for a big company to have our user’s tracked like that. We currently use Tumblr for hosting. I’d like to move towards a static website hosted on GitHub Pages, so we can have full control over the website. On the long term, the plan would be to get rid of all the trackers. That would only leave MailerLite to track some data (the number of subscribers, among others). That’s the only statistic I’m looking at.

MailerLite also gives other details, such as which link got clicked the most in each newsletter issue, etc, but I discovered it’s not a good idea to look at those. Sometimes, the most clicked link is, unfortunately, the one with a catchy title. This doesn’t say too much about the quality of the article. Seeing this made me think of adding a few words for each link, like most other newsletters do. However, this is one thing that keeps us different from the rest, and I’m not sure it’s a good idea to change that. That’s actually one of the things I like about iOS Goodies: we just share the links. I don’t think my personal opinion about each article linked by the newsletter is that important. If I linked to it, then I think it’s good. If the subscribers want to read the article, they shouldn’t need my opinion about it. I realise that writing a few words before each link would improve a lot the user’s engagement, they’ll click the links more often. But I don’t really want to do that. Our subscribers would get a list of links submitted by the community, and, in some cases, selected by me. That’s it. I don’t really want to force upon them my opinions about the articles too. I like the idea of iOS Goodies being a community newsletter, and I’m trying to keep it that way :)

Header photo by unsplash-logoEmma Frances Logan

Conferences are not dead

January 22, 2018

I read Chris Adamson’s post on conferences last week. A few hours later, I also found Marco Arment’s reply. And Friday afternoon, Dave Verwer also wrote about this in his newsletter, which drew even more attention to this topic.

While all three make some great points, there’s one thing which I completely disagree with: conferences are not a thing of the past.

I’ve been helping Luis maintain this list of conferences for almost 2 years, and I’ve been keeping my eyes on all iOS-related conferences out there for at least double than that time. I’ve participated in one conference every year since 2015 and I’ve watched lots of videos and followed a lot of the buzz around them on Twitter. I don’t think it’s the end of the conference era. Sure, lots of conferences have ceased to exist. But new ones appeared.

When I started looking into iOS development, NSConference was one of the biggest and best conferences out there. NSConf had its last edition in 2015. But other great conferences appeared, like NSSpain, or Mobile Era, or ADDC, or AppBuilders or The Swift Alps. You may notice that all those are in Europe. That’s probably because I know more about the conferences in Europe than the ones in the US or elsewhere. Or because there are actually more conferences in Europe than in the US (which the 2 other blog posts seem to be focused on).

Also, counting the conferences that are already announced for 2018, we have 28 iOS-only conferences and 16 mobile-related conferences, and there are many others which will take place but haven’t yet been announced for 2018 (Looking at you, NSSpain, Pragma Conf, Swift Alps, try! Swift India, try! Swift NYC, AltConf and others). I don’t think that’s few. Sure, CocoaConf stopping is a big loss for the US conference scene, but overall, I think there are still a lot of good events all over the world.

Years ago people went to conferences to hear the talks. Now almost all the presentations are recorded and you can watch them from home. The main advantage of going to conferences nowadays is talking to face to face to other people in your line of work. There are lots of opportunities. New collaborations can start, which lead to great books being published.

You make new friends at a conference.

I know people who got new jobs after attending conferences. I know people who got new contracts, new clients after conferences. Conferences are nice :).

But yes, they’re not perfect. There are problems. They’re expensive, they usually lack diversity (both in speakers and in participants), most of them have the same speakers, some even giving the same talk to multiple conferences. Some people say that due to the speakers being mostly the same at all conferences, some kind of “elite” is created, which does not help the community.

On the other hand, try to see the things from the perspective of the organizers. I’ve organized summer schools for around 70 student attendees in Romania, and I’m trying to organize CocoaHeads Bucharest. It’s hard. You don’t find people who want to give talks that easily. And it’s a lot of effort and you need to spend a lot of time to make an event. Now try to think of the scale of a conference. There’s a lot of work involved in making a conference. And let’s say you want to start a new one. If you bring all new speakers, people will be reluctant to attend because they haven’t heard of any of the ones giving the talks. If you bring speakers who already have a reputation, you can be criticised for lacking diversity. All those critiques have a high impact on your morale, which again won’t help with the organization of the event. And imagine doing this for years and years in a row. There’s no wonder some conferences stop having new editions.

But with all this effort required to make a conference, the number of events (at least in Europe) is growing. So hats off to you 🙇, conference organizers everywhere! Thank you for giving us opportunities to meet each other and learn together.

I’ve heard developers saying they go to conferences mostly for the people and the experience, and not for the talks. Many seem to agree that the “hallway track” is at least as important as the actual talks. So it’s clear that at least in this direction, conferences need to improve. It’s hard to say how, but some of them are trying. The Swift Alps is a different kind of conference, with a unique concept. I didn’t get to participate yet, but I’d like to, and I’ve heard good things about it. I don’t know if it’s the way to “fix” conferences, but I think it’s a step forward.

Quick summary:

  • I don’t think conferences are dead. There are more now than before. Here’s a list to inspire you: https://github.com/Lascorbe/CocoaConferences
  • Making a conference is hard and expensive. Which explains why some of them stop. And why we should be more appreciative of their organizers.
  • There are many things at conferences that can be improved, and it’s hard to know how. But some conferences are already trying (The Swift Alps, Swift Aveiro).

What this WWDC means for us

July 21, 2017

NOTE: This article was first published on the Nodes Engineering Blog in June 2017.

WWDC 2017 happened at the beginning of June in San Jose, California, and Apple presented lots of exciting changes. We already covered in this article the most important iOS additions from a user’s perspective, but what exactly did WWDC 2017 bring for an iOS developer? Continuing the trend from the last year, the WWDC Keynote was less targeted to developers, and more towards media and users. The interesting things for developers are covered mostly in the Platforms State of the Union, and in the following sessions.

Swift 4

As was expected, iOS 11 comes with Swift 4. However, since Swift is open source, and all the development is done in the open, there were no big surprises here. Ole Begemann made a playground a few weeks before WWDC showing what’s new in Swift 4, that also got a mention during one of the WWDC sessions.

There’s a new Codable protocol, which hopes to end the war of the JSON parsers; there are a lot of changes to the String type, which is now a collection again; Swift 4 supports multi-line literal strings (an announcement that was greeted with lots of applause from the developers), and support for KVC was added (and to make it better, the key paths are strongly typed). However, the best part about Swift 4 is that it is source compatible with Swift 3. Upgrading codebases from Swift 3 to 4 is going to be very easy (here’s an example of updating Codemine to the latest Swift version).

Xcode 9

But it’s not Swift 4 that got developers excited at WWDC. The greatest news, for me, at least, was Xcode 9.

Xcode 9 finally brings refactoring for Swift code. Not only that, but the whole source editor was rewritten (in Swift). The source control integration has been improved, there are updates to the build system and Xcode Server comes by default with Xcode 9.

Other noteworthy features are named colours in the asset catalogue, pure vector image support, a main thread checker, a new unexpected behaviour sanitizer, and wireless debugging.

iOS 11

With regards to iOS 11, the two new APIs that excited me the most are the new PDFView and the Drag and Drop. Drag and Drop is really interesting, especially for iPads. There is support for Drag and Drop on iPhones too, but that’s only in the same app. For iPad, however, this opens up a lot of possibilities. The whole way of interacting with files and data across multiple applications has been updated. There are a lot of new possibilities for app developers, and I can’t wait to see iPad-optimised apps in autumn.

Regarding the new PDFViewer, I’m looking forward to not having to use a web view for displaying pdfs; even though that’s fast, convenient and it worked, that always seemed a bit like a sub-optimal solution.

What’s next

At WWDC we’ve been given a preview of what our next year will be like. We’ll get new betas every approx. 2 weeks with the latest updates and changes. In the autumn iOS 11 will be released, and everyone will be able to use the apps we developed during the summer with the latest APIs and features.



Image sources: - Apple - Macworld - Ray Wenderlich

Haptic Feedback makes you vibrate!

May 21, 2017

NOTE: This article was first published on the Nodes Engineering Blog in April 2017.

The iPhone could vibrate ever since it was launched. And so did almost all the other phones, even from before smartphones were a thing. But Apple took this function further than anyone else, by introducing the Taptic Engine in the Apple Watch, and afterwards in many other products, like the new MacBooks and iPhones. The Taptic Engine provides haptic feedback, more similar to real-life touches than standard vibration.

Together with iOS 10, Apple introduced an API for the Taptic Engine, which the developers can use to give haptic feedback to their users. To fully experience the haptic feedback you need an iPhone 7, 7 Plus or newer. Even though the API is introduced in iOS 10, it’s only the iPhone 7 and iPhone 7 Plus that support this. On all previous devices, nothing happens when you try to do that.

How to create haptic feedback

Using the new API is super easy. With the UIFeedbackGenerator you can create haptic feedback with only two lines of code.

There are 7 different types of haptic feedback a developer can use. The only difference between those 7 types of feedback is the vibration pattern. Some of them are subtle, like the selection change, and others are more powerful, like the notification error.

The UIFeedbackGenerator has 3 subclasses, UISelectionFeedbackGenerator, UIImpactFeedbackGenerator and UINotificationFeedbackGenerator, and those are the ones a developer should work with. We will showing how to use them further below.

Due to the inherent difficulties of showing vibrations through a blog post, we are using the official videos of each type of feedback from Apple’s Human Interface Guidelines. You can also run the code from this repo on your iPhone 7 or iPhone 7 Plus to try it out.

Selection

This one can be used when the user has to select from multiple discrete values, as he/she scrolls through them. For example, it’s used in the UIPickerView. It feels like a light tap with each selection change. This is not to be used for example when selecting one of 4 radio button choices.

let selectionFeedbackGenerator = UISelectionFeedbackGenerator()
selectionFeedbackGenerator.selectionChanged()

Impact

The impact type of feedback is to be used to enhance a visual experience. For example, it can be used in a game when a collision occurs. I couldn’t find this documented, but I’m almost sure that Impact - heavy is the type of feedback that the user feels when a peeked view pops full screen.

Light

let lightImpactFeedbackGenerator = UIImpactFeedbackGenerator(style: .light)
lightImpactFeedbackGenerator.impactOccurred()

Medium

let mediumImpactFeedbackGenerator = UIImpactFeedbackGenerator(style: .medium)
mediumImpactFeedbackGenerator.impactOccurred()

Heavy

let heavyImpactFeedbackGenerator = UIImpactFeedbackGenerator(style: .heavy)
heavyImpactFeedbackGenerator.impactOccurred()

Notification

The notification type of feedback should be used to indicate to the user that a task has completed. Depending on the outcome of the task (success, error, warning), the feedback pattern differs.

Success

let successNotificationFeedbackGenerator = UINotificationFeedbackGenerator()
successNotificationFeedbackGenerator.notificationOccurred(.success)

Warning

let warningNotificationFeedbackGenerator = UINotificationFeedbackGenerator()
warningNotificationFeedbackGenerator.notificationOccurred(.warning)

Failure

let errorNotificationFeedbackGenerator = UINotificationFeedbackGenerator()
errorNotificationFeedbackGenerator.notificationOccurred(.error)

Using the UIFeedbackGenerator may have a little latency. If you want to use it to match some sound or visual effects, you can call the prepare() method on the generator to put the Taptic Engine in a prepared state and reduce the latency. It will stay prepared a few seconds, or until the next feedback is triggered.

When to use haptic feedback

We saw that creating haptic feedback is super easy. However, the complicated part is knowing when and where to use it.

As usual, Apple helps with this, by adding a section on it to the Human Interface Guidelines. And we can also learn a lot by looking at where the haptic feedback is used across iOS.

We all know by now that the Home button isn’t an actual button anymore, it’s just some very smartly done and well-placed haptic feedback. But that specific pattern doesn’t come by default with the new UIFeedbackGenerator. Other parts of iOS though use the exact types of feedback that the developers can access through the new APIs.

For example, when you set an alarm or a timer, you’ll notice a light tap whenever the selected time changes. Or when you type, and you hold down a letter on the keyboard to get to the various accents, the same light tap will inform you when you selected a different character.

Some controls, such as the UIRefreshControl have the feedback built in, and you will feel a small “knock” when you pull to refresh a scroll view. Same for zooming in or out a UIScrollView - zooming too much (either in or out) will also create a “knock”.

If you dig deeper, you’ll find even more creative use cases of the haptic feedback. For example, sending or viewing an iMessage with fireworks effects will send create “thuds” for every exploding firework.

To do haptic feedback right, you need to use it together with some animation or sound effects. Haptic feedback alone will probably feel out of place most of the time. Imagine getting a UINotificationFeedbackType.error feedback when you show an alert saying that the password you entered is wrong. That would be weird.

The Taptic Engine, together with the haptic feedback API has huge potential, and we are looking forward to seeing more creative usages of it.

Resources

Serpent - more than just another JSON mapping framework

April 1, 2017

NOTE: This article was first published on the Nodes Engineering Blog in March 2017.

At Nodes, we develop apps that rely a lot on complex REST APIs. The iOS team needed a fast and fully featured JSON mapping framework. We had been using our own internal parsing framework for Objective-C for a long time, but when Swift came out we decided to create a new one, in Swift, taking advantage of protocol-oriented programming.

After many iterations and a renaming (our JSON mapping framework was previously known as Serializable), we are proud to announce that Serpent has reached version 1.0.

Another JSON mapping framework?

More than that. Serpent is one of the fastest JSON mappers out there and has the most features, according to our analysis.

And maybe you only have to parse and map small JSONs, and you don’t care that much about the time it takes. But what about the time it takes to write the mapping code?

We made a tool that goes hand in hand with Serpent: with Model Boiler you only have to declare the properties on your model, and the parsing code will be generated for you, potentially saving you hours of work.

But why build a new one?

Yes, there are lots of other JSON mapping frameworks out there. But when we started developing Serpent, there was only SwiftyJSON, which wasn’t exactly what we wanted. So we needed to build our own.

In February 2016, we moved the project to a public GitHub repo and began developing in the open. At the same time, we started using this framework in all our apps, and at the moment, we can say that Serpent is used in apps with more than 1.3 million monthly users.

Working with Serpent

We built Serpent to make developers’ life as easy as possible when creating models. So we also built a few goodies around Serpent, which allow the developer to save a lot of time when creating the models for the app.

Serpent Xcode File Template

We made the Serpent Xcode File Template, which adds a new file template for Xcode. No more typing import Serpent manually. It sounds small, but when you have to create 10-20 models, it saves you from a lot of annoyance.

Model Boiler

The most annoying part when working with JSONs in Swift is typing all the parsing code. We made a tool that works with Serpent that does that for you. The Model Boiler is a small macOS app that lives in your mac’s menu bar. In Xcode (or your favourite editor), select the code for the model and its properties, and press a keyboard shortcut, and the Model Boiler will generate the necessary code for parsing to your Clipboard. You can just paste the parsing code in your model. And that’s it.

Together with the Xcode file template and with the Model Boiler, Serpent is (in our opinion) the easiest and most pleasant to use JSON mapping framework for Swift.

Why Serpent?

Here’s a short list of some of the advantages that Serpent has:

  • Its own Xcode file template
  • Its own code generator: Model Boiler
  • The best balance between speed and features. We did the tests and we compared it to some of the most popular JSON mapping frameworks out there.
  • 100% test coverage
  • Carthage, CocoaPods and Swift Package Manager support
  • Different versions of it are used in apps used by more than 1.3 million users every month (based on analytics data for some of our apps).

We’re really proud to be able to release the 1.0 version of Serpent. The biggest thanks go to all the contributors that made it possible. We hope more developers find Serpent useful and give it a try in their apps.

Serpent is open source. If you find bugs or have ideas for new features, you’re more than welcome to contribute to Serpent. And if you really like what we’re doing, check out the Nodes careers page and join us to make awesome things together.

Understanding code signing for iOS apps

November 27, 2016

NOTE: This article was first published on the Nodes Engineering Blog in October 2016.

If you’re an iOS developer, most likely you’ve had to deal with code signing. And if you’re a junior iOS developer, you might’ve felt a bit overwhelmed by everything going on in the “Certificates, Identifiers & Profiles” section of the developer portal.

The goal of this article is to help junior iOS developers understand code signing on a higher level. This will not be a step-by-step tutorial on how to code sign your app. Ideally, after reading this article, you will be able to code sign your app without following any tutorials.

I don’t plan to go into lower level details, but we will talk a bit about asymmetric cryptography.

Asymmetric cryptography

The minimum you need to know is that asymmetric cryptography uses a public key and a private key. The users have to keep their private key for themselves, but they can share the public key. And using those public and private keys, a user can prove that he is indeed himself.

A good high-level explanation of asymmetric cryptography can be found here. If you want to know implementation details or the math behind this, you can find them online.

App ID

The App ID is the unique identifier of your app. It consists of a team id, generated by Apple (you don’t have any control over it) and your app’s bundle id (com.youcompany.yourapp, for example).

There can also be wildcard App IDs: com.yourcompany.*. Those will match on multiple bundle ids.

Generally, you will have an explicit App ID, not a wildcard one.

Certificates

You have probably already noticed that in order to create a certificate in Apple’s developer portal, you need to upload a Certificate Signing Request. You can generate this CSR from the Keychain, and this CSR contains a private key.

Then on the developer portal, you can create a certificate using this CSR.

There can be multiple types of certificates. The most common are:

  • Development (iOS App Development) - You need those to run your app on a device from Xcode.
  • Distribution (App Store and Ad Hoc) - You need those to be able to distribute your app through the App Store or Ad Hoc
  • APNS (Apple Push Notification Service) - You need those to be able to send push notifications to your app. Unlike Development or Distribution certificates, APNS certificates are associated with an App ID. There can be 2 types of APNS certificates, for development - Apple Push Notification service SSL (Sandbox), and for production - Apple Push Notification service SSL (Sandbox & Production). You need to create both of them if you want push notifications to work on both debug and distribution builds.

Devices

You can add up to 100 devices per product family per membership year to your account. 100 iPhones, 100 iPads, 100 iPod Touch, 100 Apple Watches and 100 Apple TVs. To add a device to your account, you need to add its unique device ID. You can easily find that in Xcode, or (a bit more complicated) in iTunes. A detailed guide on how to add devices to your account can be found here.

Provisioning profiles

The provisioning profile is what associates an App ID with a certificate and, for development or ad hoc distribution, with some devices. You create the provisioning profiles on the Apple developer portal and you download them in Xcode.

Usage

After you have created all these, you can then go to Xcode, add your certificates, refresh your provisioning profiles and then select the provisioning profile you want. You can then select the desired signing identity (based on the certificate associated with it) from that provisioning profile.

F.A.Q.

Over the years working in iOS development, I’ve asked and I’ve been asked many questions about code signing. Here are some of them.

  • Q: I have downloaded the provisioning profiles and certificates from the developer portal, but I can’t sign the app.
    A: Yes, because you don’t have the private key, the one that was in the certificate signing request. Most likely, another team member created those certificates and provisioning profiles before. You can get the private key from the original developer, revoke the certificate and generate a new one (which will break all provisioning profiles associated with that certificate, but not any App Store apps using those) or create a new one if possible (currently, there’s a maximum of 3 distribution certificates allowed per account).

  • Q: What about the push certificates? I want my app to receive push notifications. Shouldn’t I create a provisioning profile that uses the APNS certificate?
    A: No. When you create an APNS (Apple Push Notification Service) certificate, you associate that with an App ID. So, first you have your CSR, then you create a new APNS certificate with that CSR, download it, open it in Keychain and export it as .p12, which you later upload to your push notification provider. The .p12 file will know that it’s associated with that app, and it will send pushes to that app only. That’s also a reason why you can’t associate an APNS certificate with a wildcard App ID (com.youcompany.*). The push notification server needs to know to which app it sends the notifications.

  • Q: I bought a new mac, what should I export from the keychain of my old mac for all the code signing to work on the new one?
    A: You would probably want all your keychain to be exported to the new mac. You can do that by following these steps. But if you want to export one certificate, make sure you also export its private key. In the Keychain, you have to be able to expand the certificate by pressing on the arrow next to it, and you should see a key. Those certificates are the ones that can be exported as .p12 files. Otherwise, they’ll be exported as .cer, without a private key, and they’ll be pretty much useless.

  • Q: My iOS distribution certificate expired, will my app still work?
    A: When your certificate expires, the provisioning profiles using that certificate will become invalid. On App Store, the app will still work as long as you’re enrolled in the development program. All the ad hoc builds signed with that certificate won’t work anymore.

  • Q: My APNS certificate expired, what happens now?
    A: You won’t be able to send push notifications to the app anymore. This can be fixed by creating a new APNS certificate associated with that App ID, downloading it, exporting its .p12 and uploading it to your push notification service provider. No need for an app update.

Summary

The key points I want to highlight about code signing are:

  • Each app has an App ID.
  • You need to have the private keys for all the certificates you use.
  • A debug provisioning profile associates your development certificate with your App ID and the devices.
  • An ad hoc provisioning profile associates your distribution certificate with your App ID and the devices.
  • An app store provisioning profile associates your distribution certificate with your App ID.
  • For push notifications, create an APNS certificate associated with your App ID, then download it, export it as .p12 and upload the .p12 to your push notification service provider; if you want push notifications both on debug and production builds, you have to create 2 APNS certificates, one for development and one for production.

Understanding these will help you understand code signing and save you a lot of time in the end.

Further reading