There’s an entire slew of new features available in iOS9 — but there’s one that you’ll be using every single day. It’s called Go Back to App and it’s all over the place. If you open an app from another app, instead of doing a full “flip” like you tapped the home button, iOS slides the app in and you get right to work. It happens so smoothly that it’s hard to even see happen:
This is going to change how iOS apps are made. Combined with Universal Links for opening up http:// and https:// links from Safari (or anywhere) inside your app, the reality for how apps are opened and work together has forever been altered. I know Apple loves calling features amazing — but this time they’re right.
We’re looking for a programmer to lead us on Android and push us further into the platform. This is a unique opportunity: we don’t hire often! We’ve got a serious foothold in the ecosystem, and we want you to take us to the next level.
We’re happy to welcome applicants based anywhere around the world. Our office is based in Chicago, but our team is spread out over multiple countries and time zones. You can work from anywhere! We’re so serious about working remotely that we even wrote a book about it.
Basecamp offers benefits for the long run, including: 4 day work weeks during the summer, an exercise and CSA stipend, a 1 month sabbatical every 3 years, maternity and paternity leave, and health insurance that covers children, marriages, and domestic partnerships.
Who are we looking for?
We’re looking for someone who lives and breathes mobile, and especially on the Android platform. Fluency in Android’s patterns and APIs is a must. (Half-hearted iOS ports drive us crazy too!) We would love to talk to a developer who has experience shipping applications with a team, or independently on your own projects.
What will you work on?
You’ll work on our mobile team to support and improve Basecamp for Android, side by side with our other programmers, designers, and QA team that enable our customers to get their work done better on the run.
You’ll join the our team of programmers who work on our Rails and iOS apps. Basecamp is the home of Ruby on Rails, and we’ll be happy to introduce you to our infrastructure. Part of being a programmer at Basecamp is our on-call rotation, where we help fix day-to-day issues for our customers using our products.
We also believe strongly in putting everyone on support, which usually happens around once a month. If you have some experience with Rails, that’s a bonus—but not a requirement.
How can you apply?
We love cover letters. They’re a great way to introduce yourself, but don’t be afraid to surprise us in other creative ways too. We want to see what you’ve built and shipped, so any existing applications on the Google Play Store that we could try out would be great to include.
We’ve filled this position. Thanks for your interest!
Our setup at Basecamp for testing our iOS apps is pretty neat. It (synonymously) involves Xcode’s CI Bots, but that’s easily the most uninteresting part of it. Here’s how we continuously integrate our iPhone and iPad apps at Basecamp and get build results into our Campfire.
Build your bot
This is easily the trickiest part. However, it is pretty boring. Once you’ve followed Apple’s tutorials to setup OSX Server and the Xcode service (which I will skip or lose pretty much everyone reading this for several hours), you just need to head to Product > Create Bot inside of Xcode.
I recommend creating an empty Xcode project first to just make sure everything is working – don’t start with your main iOS codebase. I named it “Placebo”.
We have some specific settings on our bots. Here’s a screenshot for each screen in the bot wizard, since there’s no way to share them outside of the Xcode walled garden. The first screen is the easiest:
Almost 2 years ago I wrote about our approach to building our first in-house native application. This week, we shipped version 2.0 of Basecamp for iPhone, which now shares a codebase with Basecamp for iPad. I’m proud to say this is our best iOS release yet. Give it a shot!
Fragmentation isn’t just Android’s problem anymore.
Here’s the last 2 years worth of iOS and Android usage by operating system version for Basecamp, combining our native app usage and our mobile web views:
Fragmentation is the past for Android, but now it’s the present for both of the major mobile operating systems. My big question: will we see either platform be able to converge in the future, or is this the new normal?
We’ve been doing iOS development in-house at 37signals for over a year! Since the launch of the Basecamp for iPhone app we’ve had a lot of questions about our development & design process going mobile, our opinions on the new environment, and more. Recently our team has participated in some interviews about how we made the app, and I think you’ll learn a lot from them.
Ryan was interviewed by Hipmob about the design process of the app, and the issues we’ve faced on mobile platforms:
The biggest challenge for a company like ours is to change our way of thinking because, we grew up when the web was just a laptop thing. We learned on laptops and we defined our notion of what software is on laptops and desktops, and it’s really changing.
Check out the whole interview transcript for more great perspectives and insights on mobile development.
I was lucky to be invited to the 4th monthly MotionMeetup, a moderated Q&A session with various RubyMotion developers. They asked questions about what I learned making the Basecamp app, what advice I’d give to newcomers to the platform, and why I hate bees:
I’m running a conference, NickelCityRuby, in my hometown of Buffalo, NY this fall. I’m no stranger to getting people to code or work together, but organizing an event like this is a new challenge for me. My main goal with the conference has been simply to bring plenty of awesome people to see Buffalo, but another of mine has been to ensure the conference is as diverse as possible. Full disclosure: 37signals is a sponsor of NickelCityRuby.
Diversity is a tough subject in the tech world, and I think it’s something we just can’t ignore. I care about this deeply because I’ve witnessed exclusion happen before (myself being at fault too!), and the only way to make sure it stops is by making conscious decisions to change for the better. There have been severalscandals at conferences recently, and this has been my biggest fear of about organizing a conference: Can we deliver a conference that is diverse?
We recently announced our speaker lineup, and I’m really happy with how diverse it turned out. However, I think this is just the beginning of making sure we meet the mark. By no means is being inclusive a checkbox you can just tick off while organizing something: it has to be baked into your decision making process from the start. Here’s a few things we’ve done so far that I think any similar event should think about.
The latest Basecamp for iPhone release involved an immense amount of refactoring with how HTTP requests and HTML pages were rendered. In a previous release, my coworker Sam wrote several methods that didn’t serve to reduce duplication, but instead their purpose was to increaseclarity. Since the focus is on comprehension rather than just reusability, it’s easier to understand what is going on and jump in to solve the next problem.
This pattern has been eye-opening, and I’ve been using it to hide implementation details and remove comments explaining what chunks of code are doing. Instead, the name of the method explains what is going on. The gist here to communicate Intention Not Algorithm:
