[Swift] SnapKit vs AutoLayout & Pros and cons of using 3rd-Party

 

 

SnapKit vs AutoLayout

- 코드 Base로 Programmatically하게 UI를 구현할 때 마주치는 고민

• SnapKit is a powerful auto layout library with a minimal amount of code to minimize developer work in managing constraints.
• SnapKit doesn't really solve any problems inherent with IB. It all boils down to user preference, though my personal recommendation is to stick to IB because that is the standard layout tool and it's very powerful. If you're using SnapKit just because IB seems intimidating, I think it's worth the time and effort to learn the IB basics
• Using 3rd party convenience libraries is a great way to have huge legacy issues in the future when Apple changes something in core. Just learn to use constraints properly. you'll be a better developer for it. 
  -> 3rd party 사용을 지양하자

 

 

 

• I hope it’s pretty clear to you that each have their own advantages
  Cartography probably has the fewest surprises, EasyPeasy is extraordinarily concise, SnapKit has extremely clear syntax that makes it easy to read, Stevia is ridiculously powerful, and TinyConstraints really lives up to its name – it’s tiny. (SnapKit을 포함하여 autoLayout을 대체할 다른 라이브러리들도 많이 있다. 이들의 장점을 정리한 글)

 

 

 

• So, talking about creating constraints programmatically, it’s not that difficult to specify them as far as you know the kind of constraints you need and how they should be combined.
  But this is often proved to be a cumbersome work because a lot of stuff is needed to be written in order to set all constraints up properly.
  At the end, it’s easy to end up with big fragments of code that configure constraints which describe the relationship between views, offsets, constants, and so on, but it’s hard to read and modify them.
  And here’s where SnapKit gets into play.
• With SnapKit it’s extremely easy to create and setup constraints, as the technique that it offers to do that is quite simple, and on top of that the amount of code required is way less compared to the traditional way.
  This inevitably leads to a great advantage;
  we have a cleaner, easier to review code, which is better manageable than before in most cases.
  Moreover, it’s easier to focus on the constraints only, without bothering to provide arguments to built-in functions that we don’t really care about.
• Reaching to the end of this post, I hope you appreciated the benefits of using SnapKit for setting up your UI programmatically.
  From my point of view, the less and clearer code, as well as the simplicity it offers in combination to the final results consist of a well working recipe.
  On the other hand, that doesn’t mean that we should forget forever how to make constraints programmatically using any of the available iOS APIs.
  And there’s always the constant risk: It’s a third-party API, so one day may not be maintained any longer.
  But for as long as it’s there, it’s a really cool, developer friendly tool.
  And focusing on what we learnt here today, I can safely say that most of your needs are going to be covered. 

 

 

• There’s an old style of defining auto layout rules in Swift.
  This style however takes considerably long time to execute.
  While you get the benefits of coding UI without visual elements; syntax is bad for no good reason. 
• This is the best option you could go according to my experiences in the industry.
  Using these libraries you get a nice looking syntax;
  you don’t have to redefine every element or constraint (UI rule) in code again and again, you can work without having to swap between code and UI screens; you will almost never get any conflicts compared to XiB’s or Storyboards.
  Listing of pros goes on and on. Cons is this being slightly advanced for someone who just started iOS Development, HOWEVER you can easily adapt yourself to it if you spend some time.
  Best known libraries for this are: 1)Snapkit 2)Purelayout.
  I used to work with Pure before; now I’m using Snapkit since I find it’s syntax nicer. 
• + 초반 도입부에, UI Component의 제약조건에 대한 설명이 인상깊었다! 

 

 

 

iOS 3rd Party Examples

1. SnapKit (iOS) – library for building application layout from code, helping developers to be more productive and achieve more with fewer lines of code,
2. Lottie (Android) – library for designing animations that developers can enrich with interactions, you can find example animations here,
3. Moya – (iOS) library for networking and communication with the backend, very popular among iOS developers looking to save a few days of work.

 

 

3rd party 사용의 장점

 

• improves the efficiency of the app development process,
• increases the quality of the product,
• reduces app development costs significantly.

Pay just for what you need

When using a third-party solution, you pay a monthly fee for the used limit instead of having to pay a high up-front cost for building the feature from scratch. Sometimes you pay the fee after passing a set limit – at the beginning, you might get away with not paying anything for using the solution. 

Faster development process

The greatest perk of using third-party software is that developers don’t have to write everything from the ground up. For example, if you’d like to add a login feature to your app, your team can simply use Auth0 and focus more on the features that form the core of your app and its competitive advantage. It makes the app development process much much faster.

Significant cost savings

Using third-party services comes at a much lower cost – both upfront and during the app’s operation over time. Some third-party platforms might be available free of charge until a certain level. Then it’s likely that you’ll be paying a monthly fee for the used resources. As a result, the cost of using a feature is spread over time, and you end up paying monthly fees instead of a high upfront fee.

 

 

 

3rd party 사용의 단점

Less flexibility

Naturally, using third-party solutions comes with some limitations.
When we’re not using the default methods supported by the solution provider, we usually need to work hard to adapt the provider’s tool to our needs. Developers can do that, but at some point, it just becomes too expensive.

If you’re looking to build a feature that is really original / custom, finding the right third-party solution might be impossible.

Also, it’s smart to consider the migration costs before jumping on the third-party bandwagon. For example, it’s common to use third-party software for authentication during MVP development. But then it might turn out that the flow of logging in needs to be changed because of the market specificity and user needs.
For instance, we might need to add a new field where the user states their height and limit that value to 2 meters.

This is when you move to custom code and solution. The cost of this migration is different in each case. That’s why analyzing this cost at the project’s outset is a smart move.

Vendor lock-in

When using a third-party solution, you’re inevitably dependent on the provider. (제공사에 대해 의존성이 생김) This poses a risk to the stability of your software. That’s why it’s a common practice to write core application features from scratch and use third-party solutions only for its non-core elements.

Risk of rising costs

Being dependent on the provider also means that the application’s costs might go up when the provider changes the pricing. (유료 서비스일 경우) It sometimes happens that the costs of third-party solutions grow drastically at a certain scale.

How to minimize this risk? Avoid building core application features with third-party solutions. While this risk isn’t that important in MVP development where you’re looking to verify the idea when scaling the app, consider whether this risk is acceptable to you.

What’s more, at some stage of application growth with a rapidly growing scale, the costs of using a given 3rd-party platform may increase drastically. It may turn out that because of scaling up, a particular solution is no longer cost-effective for you.

 

 

 

Our recommendations for using third-party software

Have a plan b

It’s worth asking yourself: what happens when we’re forced to stop using a third-party solution for some reason? It’s good to have a plan b – a migration strategy where you list all alternatives to your solution. The strategy should also point out how your own solution would be implemented and estimate the cost of migration both between different providers and between a provider and your custom solution.

Consider the feature at hand

When deciding whether to use a third-party solution or write up functionality on your own, ask yourself these questions:

• Is it a core or non-core feature?
• How important is this feature for my application?
• If it’s a non-core feature, how often will it be used?

Your answers will indicate whether third-party software is a safe bet.

Decide whether you’re building something specific or generic

If you’re looking to build a generic functionality, it’s worth it to use third-party software. But if what you need is something specific – something that a third-party solution might not deliver – just don’t use it.

Note that some platforms allow adding custom components. So, if a third-party platform doesn’t include everything, check whether adding a feature could be an option.

Consider changes and don’t get attached too much 

Even if you used a third-party solution for your MVP or product, it doesn’t mean that you need to stick to it at all costs. Changes are normal in software development. Your application is bound to change due to the changes in the market, among your customers, or in your business. And so will its technical requirements. Migrating a feature to code written by your development team is a common scenario, so there’s no need to be afraid of third-party software.

 

 

 

 

 

✳️ 장점

• 간편하게 레이아웃을 구현할 수 있다. 
• 복잡한 코드가 간결해진다.
• 레이아웃 구현에 집중할 수 있다.

 

⛔️ 단점

• 3rd party 라는 위험성이 내포되어 있다.

3rd party 사용의 장단점을 고려하여, 각자의 상황에 맞게 결정하자

 

 

 

 

 

 

 

출처

• https://medium.com/appcent/swift-5-autolayout-in-code-in-depth-tutorial-best-practices-snapkit-examples-1fd8be6b55ef
• https://www.appcoda.com/snapkit/
• https://www.hackingwithswift.com/articles/9/best-alternatives-to-auto-layout
• https://stackoverflow.com/questions/41347067/what-advantages-does-snapkit-have-over-using-autolayout-in-interface-builder
• https://www.thedroidsonroids.com/blog/third-party-software-pros-and-cons
• https://appleglitz.com/snapkit-for-ios-limitations-in-a-snap/