We are all too familiar with the unpleasant experience of a native app crash. You’re happily playing your favorite game, queuing up the next video, researching the next piece of furniture to buy (hint: Wayfair may help!) when all of the sudden, POOF! The app is gone and you’re back to your phone’s home screen. Those who are less technically inclined might not even know that this was an app crash, or worse, they may think that somehow their actions were responsible for the un-magical disappearing act. Android is slightly more helpful: after a crash, the user is presented with a dialog that tells them that unfortunately, their favorite app has stopped. Unfortunate, indeed. But just how unfortunate? This post explores the return on investment for fixing crashes. Keep reading to learn what we learned.
9 Min Read
When it comes to mobile platforms, Wayfair has multiple end user focused apps across iOS and Android, with over 100 engineers working on them. As the recently appointed lead of the App Team here at Wayfair, I chose to ask fairly generic yet consistent questions upon my arrival to get the lay of the land. These questions included:
9 Min Read
Here at Wayfair, we are faced with challenges that the average iOS developer likely never has to come across. In the last eight months, we’ve had 47 different developers make 2,000 commits into our repository. Over the past six years, this monumental amount of changes has led to a codebase consisting of thousands of files and nearly 430,000 lines of code. Each day that goes by, we have around 10-15 merge requests go into our master branch, and 50 more open at any point in time. All of this code takes a toll on the compiler, and even though it has been extremely gradual over years of work, it has become increasingly easy to see that app compile times are slowing down our productivity exponentially.
10 Min Read
The Wayfair iOS app aims to have complete feature-parity with our website. This means that we need to support a variety of screen sizes and orientations in ways that — at least from an iOS frameworks point-of-view — are “custom”. To be specific, we need to support three distinctly different layouts, each with its own view hierarchy and behavior: iPhone portrait, iPad portrait, and iPad landscape.
11 Min Read