Technology Selection and Architecture Choices for Mobile Apps: Native vs H5, Swift vs Objective‑C, and MVC/MVP/MVVM

Native/H5

Debates about using native code versus H5 (HTML5) have never stopped, but the choice should be driven by the actual scenario. In the current project we need Android and iOS apps as well as a WeChat public account, have very few part‑time H5 developers, are comfortable with native development, and have only a half‑month to deliver.

Develop both Android and iOS apps and a WeChat public account.

H5 talent is scarce and unreliable.

Our team is more familiar with native development.

Development time is only two weeks.

Given these constraints, most pages are implemented with native UI to keep risk low, while a few pages that can be built with H5 are loaded in a WebView. Loading server‑hosted H5 pages is simple (just load a URL), whereas loading local H5 assets is more complex but faster; the project chose the simpler server‑hosted approach.

If resources were abundant, the author would favor H5 as the primary solution, using native code only for app‑specific features such as navigation bars, titles, and login screens. In a hybrid app, H5 pages are loaded in WebView, and any click events that need native handling are intercepted and redirected to native pages, which may embed another WebView for subsequent H5 content.

Objective‑C/Swift

The author chose Swift for three reasons: its concise syntax and high productivity, the inevitable shift from Objective‑C to Swift, and the fact that only one developer (himself) works on iOS, so team‑wide language concerns are irrelevant.

If a team lacks Swift expertise, stick with Objective‑C; if a few members know Swift, mix the languages and encourage others to learn; if everyone knows Swift, use it exclusively.

For dependency management, the author prefers Carthage (written in Swift) over CocoaPods because it is lighter‑weight and more flexible, and he finds CocoaPods cumbersome and tightly coupled.

Recommended Swift libraries include:

Alamofire – the Swift networking foundation library (author of AFNetworking).

AlamofireImage – image loading built on Alamofire.

ObjectMapper – JSON‑to‑model conversion for Swift.

AlamofireObjectMapper – combines Alamofire and ObjectMapper to automatically map JSON responses to Swift objects.

MVC/MVP/MVVM

A brief overview of the three architectural patterns:

MVC (Model‑View‑Controller) – classic and easy to understand, but the View often depends on the Model (introducing business logic into the View) and the Controller can become overly complex.

MVP (Model‑View‑Presenter) – replaces the Controller with a Presenter to decouple View and Model, solving the first issue but leaving the second.

MVVM (Model‑View‑ViewModel) – builds on MVP with two‑way data binding, so changes in the View automatically update the ViewModel and vice‑versa.

Each pattern has its own strengths and limits; more advanced patterns increase complexity. The author does not advocate a single “best” pattern but chooses based on current team size, resources, and timeline, while keeping future extensibility in mind.

Conclusion

Technology selection is less about the intrinsic merits of each option and more about matching the solution to the team’s skill set, available resources, and project stage. As the team grows and resources increase, revisiting and possibly refactoring the architecture becomes necessary.