Smartphones have been in the market for a while now. After some comings and goings of different players, Android and iOS were established as the main contenders and now represent almost 99% of the global market share. Because of that, virtually any new app idea will focus on these two platforms.
In this article I’ll be talking about the main differences and similarities that every designer should consider when designing UX and UI for iOS and Android. You can be starting from scratch or already have a published app that needs to be adapted for the other platform. For both cases, I’ll be constantly linking the platform guidelines, as they are the main source of reference when designing a new interface.
Hybrid technologies have been employed for quite a while in mobile application development. Frameworks such as PhoneGap and Ionic come with an appealing motto: Develop once, run everywhere. And they actually do what they promise: you write a web-based app once and release it everywhere, from iOS to Android and the Gates of Mordor, as long as it gives support.
I do believe that they play an important role in the mobile app development scene: the huge community of web developers can write mobile app code and are able to deploy fast. But, in my opinion, the idea of developing one shared application for all platforms is dead per se.
As an iOS developer working at a startup focused in collaborative development, I’ve been involved in several projects so far, and most of them share common tasks such as downloading and caching images, performing network requests, and building Auto Layout views.
At first, I had a flow that I thought was good enough to accomplish these basic tasks (or any other, for that matter):
- Try to implement using the iOS SDK
- Get stuck at a problem that doesn’t have a straightforward solution
- Look up the solution on StackOverflow and implement it
- Move on to the next task
That seemed like a good flow at first, but got a bit tiresome in the long run – after all, nobody likes to hack for a living.
Let’s face it: developing scalable front-end code isn’t piece of cake. No matter how well-structured the framework/architecture you’re using is, everything will be converted to ye olde HTML, CSS and (vanilla) JS.
Well, the good news is the open-source community already created solid frameworks (like AngularJS and ReactJS) to make your life incredibly easier, so you can work on high-level code and nevermind the hardcore stuff.
This brings up a new scenario, though – after getting used to building things the old-fashioned way (or not-so-old-fashioned, with tools like Backbone.js or Ember.js), you’ve decided to try what is trending on front-end development now: ReactJS, using the Redux architecture. You got excited with the possibilities this opens (and – oh my! – the ability to ditch jQuery once and for all), and, after working for a few weeks you realize that your code is a total mess.
If you’re either a UI designer or a developer, you’ve probably heard of Sketch in the past years – or maybe you’re even using it. Sketch has become a very popular software and broadly used by UI designers. In this article, I’ll show some steps of my workflow when creating and exporting assets to mobile or web applications.
I hope that this article will be useful for designers starting to use Sketch or developers who need to export assets from a Sketch file. If you’re already experienced with Sketch, you’ll probably be familiar with most of the things I’ll be presenting, but you can still get some good insights from this article.
A common way to describe a product development process is with the Design – Front-end – Back-end stack. This approach takes into account the disciplines involved on the process, and though it helps making things understandable, the distinction enforces the idea that the process is linear and phase-dependent.
This linear flow can also be defined as the waterfall model, and it’s rather common in the web industry. All pages are designed upfront, then a set of mockups are handed off to be translated into front-end code, and then, after all of that, the back-end logic is created. This causes an isolation of professionals on each phase, which leads to a series of implementation issues, mostly due to the difficulty of foreseeing all details and use cases on the early stages.
It also leads to the notion that there’s “my work” and “your work”. It’s not rare to hear developers saying: “Designers can’t touch my code!” or designers complaining that “The front-end developer messed up my layout!”. This creates barriers to the process. As obvious as it might sound, everyone is working towards the same goal: building outstanding products. And a more collaborative process is the way to achieve that.
Android is an awesome platform that enables you to impact millions of users, but, even after so many years in the market, there are still several basic problems that are still a pain to solve and haven’t been included in Android’s core Software Development Kit.
In order to solve these key problems, I’ll point some great tools and libraries – developed by the Android community – that are widely used and a breeze to work with. They are all open source, available on GitHub and actively maintained. Now, let’s start!
In the past few years, websites have evolved into complex web applications, and what once was land of simple business informative pages, now is home to Facebook, Slack, Spotify and Netflix, changing the way you communicate, listen to music or watch movies. Front-end development has reached a new level and now requires more attention than it used to.
However, when an application grows considerably, a couple of issues start being more frequent than expected: you forget to update all places where a value is displayed in the UI, no events are bound to the content added by AJAX, just to name some — this list can be very long. These are signs that your code is not maintainable, especially when developing together with a team. Using a front-end framework provides a formal way to write collaborative code that you can read, write and update.
We all use a lot of web applications, such as Gmail, Evernote, LinkedIn or Telegram as productivity enhancers in our daily lives. However, there are not-so-rare moments that these services go down for a variety of circumstances.
In a recent event, due to Brazil’s Department of Justice decision to block access to WhatsApp in the whole country for 48 hours, millions of Brazilian users suddenly migrated to Telegram, generating a huge (and unexpected) load in their servers. Since this is not the first time this happens, Telegram was well-prepared and handled the usage peak gracefully (even though there was an SMS service bottleneck).
However, in a previous user base sprout, Telegram had a 2-hour outage in some parts of the world, as they said in their official Twitter.
Don’t get me wrong: I think Telegram was totally on top of this. The fact that they could solve this issue in a 2-hour window says they were prepared for cloud scaling – which unfortunately isn’t always true for all web services.
So how can you prepare for scaling? How can you be sure the cloud service you’re creating is prepared to handle a big user base (or a sudden increase in access) without going down?
When developing an iOS app, it’s important to think about what iOS project architecture you should use. Most developers use the pattern suggested by Apple: the so-called MVC (Model-View-Controller) architecture. However, as well-established as it is, the MVC has its flaws. For one, because of its simplicity, it leads even the most experienced engineers to put any code that doesn’t belong to a View nor to a Model in the Controller’s logic – generating huge chunks of code in the controller and really compact views and models.
In this post, we’ll present VIPER, one of the trending alternatives to MVC that might help you overcome its limitations while keeping your code modular and well-organized, improving your development process.