Yesterday, hell froze over.
Many people have written about the change in Apple’s external engineering culture. With the announcement of Swift at WWDC 2014, Apple seemed to have relaxed its notoriously tight-lipped communications: Chris Lattner is candidly answering questions in the developer forums, there’s a Swift development blog and I’ve even had a radar resolved! While matters are definitely changing for the better, a company of Apple’s size has insane inertia and good things take time.
So it comes to little surprise that, when ResearchKit was announced as an Open Source project, many members of the community were skeptical. But where the “old” Apple would have handed a zip archive to registered Apple Developers and called it a day, the new Apple now has a GitHub account.
A GitHub account. Apple.
I don’t think anybody would have imagined this two years ago (cue the never
happened under Steve) but there’s even more: the ResearchKit team have
expressed interest in adding a
podspec for official CocoaPods
I’m glad they understand that in order for ResearchKit to succeed, they need to get it as many developers’ hands as possible and CocoaPods has done a lot to lower the barrier to entry for using third party dependencies.
However, if Apple can step up their Open Source game, we can too.
The Pull Request to add the aforementioned
podspec file quickly filled
with 👍s. While I understand that those emoji were well intended and only meant
to express support to the cause–hey, it beats duping a radar–the thread got very
noisy very quickly. As someone who maintains some Open Source repos myself, it
pained me to see that the ResearchKit team’s first foray into the public iOS
community was met with such clutter.
Again, I’m sure that those 👍s had only the community’s best interests in mind, but I think there is a certain sense of entitlement in our part of the Open Source world when it comes to support for some random iOS version, the dependency manager of the day or fixes for arbitrary crashes in your app, which may or may not be related to the project in question.
Let me tell you, nobody likes to maintain iOS 7 support in their spare time.
Bumping or 👍ing that issue for the twentieth time is probably not going to do anybody much good. The thread becomes harder to follow for everybody and the maintainers get more email at best and a sense of guilt at worst.
Open Source projects rarely come with a Service Level Agreement. There are many reasons to pursue Open Source just as there are many other interesting things in life. Look at the list of contributors to your favorite OSS project and imagine what would happen if they all pulled a __why, as they have every right to.
If you decide to incorporate someones project into your app, especially if you write said app as part of your day job, you have to be willing to support that project when the poop emoji hits the fan. That can mean using your own time and engineering resources or financially supporting said contributors. I don’t think many people would balk at the opportunity to get paid for working on something they started out of their own curiosity.
But maybe money is tight and you don’t have the knowledge necessary to support every project. That’s cool. If you don’t think you have the skills to fix a problem yourself, try regardless. A Pull Request will always get you further than an Issue. Even if it breaks the build, it shows that you value the maintainers’ time highly enough to match it with some of your own. It’s also a great opportunity to familiarize yourself with a code base and learn a thing or two.
Update: Thanks to Ayaka and Orta for their Pull Requests on this post 💛.
After a long wait, Mantle 2.0 is finally here. I got the opportunity to write most of the additions and learned a lot from Justin’s insightful code reviews.
For those that upgrade, it brings rock-solid error handling and makes it easier to extend adapters to handle reoccurring transformations. Check out the whole Changelog for the nitty-gritty. I’ve been using it in production for a while, and it being so solid was probably the main reason why the milestone was stalled at 95% completion for so long.
Sadly, I don’t think we’ll ever see a Mantle 3.0., now that Swift shows us a clear way forward in terms of value types and immutability that is not really compatible with Mantle. It’s fundamentally an Objective-C project.
That being said, you should definitely have a look at my buddy Felix’ Pistachio framework, it shares many of Mantle’s ideals and is easy to mix with specific serialization formats, like Argo for JSON.
I hope you find Mantle useful and if you use it production, I’d be happy to hear from you.
Josh Abernathy just open-sourced his take on ReactNative, Few.swift:
Few.swift lets us express UIs as stateless, composable, immutable-ish values of their state. When their state changes, Few.swift calls a function to render the UI for that state, and then intelligently applies any changes.
To put it another way, the state is the necessary complexity of the app. The view is a mapping from state to its representation.
This is super cool because the only thing that’s mutating is the state. Few.swift is in charge of making an in-place changes to the UI when the state changes.