Creating a leading fashion platform requires thinking outside of the box, finding eloquent solutions to complex problems, and, ultimately, approaching them with the user experience in mind.
Being an iOS Engineer at ASOS, my role encompasses all of the above.
Developers must be allowed to express their creativity and take part in problem solving activities — whether it be building a beautiful user interface or creating in-house tools to assist in streamlining processes.
Not only does this keep development projects well maintained, and the team motivated to deliver, but it also fosters a forward-thinking mentality.
How can this be achieved?
So, you’re working on a project with many team members, or perhaps you’re writing a framework. Both involve writing code which other developers will most likely look at or use in some way, whether it be adding new functionalities, or accessing your functions from outside.
If you’re working independently, it’s easy to get into the bad habit of jumping straight into writing the implementation and improvising as you go, only to come back to it later the same week, finding that you, or any of your colleagues, can’t read any of it.
This will result in new functionalities taking longer…
Preface: This article covers some intermediate topics and makes use of some external libraries. If you’re brand new to Swift, I would recommend reading up on Protocols, Generics, the Codable Protocol, Alamofire (networking library) and PromiseKit (see my article).
Now that that’s out of the way…
Does your app have to deal with some JSON server?
Do you have a single class in your project named JSONClient or APIManager?
Does it have a separate function for each JSON request causing lots of duplicate code?
If you answered yes for any of the above, or your code looks a little…
As an iOS developer, and as someone who has had experience in multiple client-facing roles, I have noticed that more and more people are becoming drawn to the hybrid solutions offered as an alternative to fully native.
The main selling points touted include reduced development and maintenance costs with a quicker delivery.
This article will explain how that this is just not the case and explore how going hybrid, instead of native, will harm the success of your app and increase costs.
When going hybrid, your app will always remain months behind their native counterparts. Newer versions of Android and…
Today we kick off the series with a popular one — PromiseKit. Its Github repository sits at just over 10,000 stars at (the time of writing) with its first release being in early 2014. It’s fair to say it has its supporters.
It promises (ha-ha) to simplify asynchronous programming. This article will cover the more common usages and evaluate factors such as documentation, ease of use and how much of an impact it can have on your project, before giving a final verdict on whether PromiseKit fulfils its goal and if you should consider including it in your next app.
Working at a company with multiple ongoing projects and a large iOS team has its challenges when it comes to ensuring high code quality with maintainability and scalability. Without a good foundation to work from, projects can quickly sprawl out of control.
One of the core skills a programmer will need to learn is the DRY principle. Don’t Repeat Yourself. Following this principle will result in not having to write duplicate code, which in turn will help towards improving project architecture. In my experience, complete files have become redundant, and solutions have been reduced to a fraction of the lines.
iOS Engineer @ ASOS