Beauty Me Case Study: iOS with Swift

Diep Nguyen -

At previous post, we had talked about designing and developing an administration dash for our project. Using AngularJS with MVC pattern in mind helps us to reduce complex about management session while reusing many view and saving resource load cost.

Today, we would like to talk about the mobile part, start with iOS version. Recall that the Beauty Me want to be a mobile-first project. Which mean:

Mobile first requires a new approach to planning, UX design, and development that puts handheld devices at the forefront of both strategy and implementation.

Focusing on handheld devices means our service will be run and provided in mobile devices first. And with this project scope, we do not want to have a web application, or, at least for now. So, we choose to serve only Android & iOS due to low priority and other platforms do not have enough interesting with us.

[Technology Choosing

iOS is a major platform which evolve through years. Objective-C has been proven to be a robust language, with many and many experts out there, even case studies or Q&A on StackOverflow. Using Objective-C to develop an iOS app is something mainstream.

However, Swift – a new language introduced by Apple for iOS development – is rising since its begin. More modern syntax, lambda support in concept, and many more, new features make it a elegant language. However because it is a newcomer, then the world is not fully filled by Swift experts or we can be afraid that we should have a situation with Swift that we can’t resolve or find help from others.

We need to choose one, before the project has been started. Then we go for iOS with Swift.

Because, we think the weaknesses of Swift are not heavy reasons, we can deal with it, and lack of experiences as well as informations can only be resolved if someone decide to do it first. Using Swift helps us to go to modern world instead of old man Objective-C. And when iOS continues evolving, we can catch it easily.

Problems and Solution

Many problems are risen when we choose Swift. First, dependency management.

CocoaPods

Sometimes you do not want to depend on anything, but another times, you want to avoid to reinvent the wheel. So you have to choose third-party libraries or plugins. You want to get the source and drag it to the project so you can directly access to implementation. But except you want to customize those folks, almost times you just want to use it as provided. Directly using source code make us hard to maintain versioning, as well as it makes version control more busy to track more source. Whenever you want to update to new version of the library, you have to carefully clear current version, then replace all of files with newer version from its page.

![BeautyMe_Cocoapods](

CocoaPods is an excellent dependencies management. We have a flexible choice and management, we can add or remove the dependencies anytime we want without making the workspace a mess. And if we just want to include the source inside versioning, we just remove the ignorance of Pods directory to have all downloaded libraries to be included in Git.

Networking with Objective-C or Swift?

Our app will require networking alot due to REST API. With Objective-C we have well-known AFNetworking to do anything we want. But due to AFNetworking is Objective-C based, we have two options:

  • Use AFNetworking as intended, and use XCode compiler to have it work with Swift inside app.
  • Use another excellent library: Alamofire, which is written purely Swift. It is from author of AFNetworking so we can ensure about its quality. However it does have some caveats.

We believe that Alamofire is better, because it is pure Swift, it means that it is suitable with our want about evolving framework. AFNetworking belongs to old years and while it is perfectly worked, we want to go with newer one to ensure maximum cooperation with Swift.

But we have some problems with the Alamofire:

  • Alamofire requires iOS8 to use with CocoaPods. We want to support iOS7 as well, so we have to directly include Alamofire source code inside our project, which eliminate helpful of CocoaPods.
  • Alamofire does not support multi-part POST, at least at the time of writing. AFNetworking can natively handle this feature to provide photo-upload feature of the app. With Alamofire, we have to manually write the multi-part function, by creating request, setting its body and parameters then send the request by ourself.
  • UPDATE: it supports multi-part for now!
  • Alamofire does not have support for integrating REST style API with POJO model. We have to do it by implementing constructor which accept a NSDictionary for our model classes.

So you can see most problems can be resolved by ways.

Project Structure and Storyboards

We have a few developer working with this project, so storyboard is a good choice as its provide an overview for all teams to look at current state of project. We have the iOS project like this:

![BeautyMe_iOS](https:We have several groups:

  • Controllers: contains all our ViewController, include base class and organized by functional hierarchy.
  • Extensions: contains all our extensions, or so called categories with Objective-C. We also transform some popular Objective-C categories to Swift extensions too.
  • Global: global functions, constants, and theming.
  • Model: POJO classes.
  • Service: related to session management and network requests.
  • View: all custom views to be used inside app.
  • The delegate class, storyboard file and image resources are placed at top-level directory due to their uniqueness.

Now we are ready to ship the code and bring the code to a product. In next post, we will talk about Android counterpart and see what happened with us in Android development. Stay tuned!