Identifiez et bloquez toutes les combinaisons possibles de numéros de démarchage d'un seul coup. Pas besoin d'avoir recours à Bloctel (qui est inefficace de toute façon), et strictement aucune chance que les appels de démarchage ne vous atteignent.

Les appels intempestifs ne seront qu'un lointain souvenir.

Il suffit de télécharger cette application gratuite Anti Spam :

https://apps.apple.com/fr/app/antispam-bloqueur-de-num%C3%A9ro/id6504856330

Installez l'application, et lancez l'identification des numéros. L'application va alors identifier les 12 500 000 combinaisons possibles de numéros de démarchage téléphonique en se basant sur les données officielles de l'ARCEP, et une fois terminée vous aurez une petite indication sur l'écran d'appel ainsi que sur le journal d'appel sur chaque numéro étant un numéro de démarchage commercial.

Tout cela est gratuit et vous permettra de ne plus perdre de temps à répondre à ces appels insupportables.

Pour passer au niveau supérieur, vous pouvez prendre la version payante de l'application et complètement bloquer ces numéros pour ne plus jamais recevoir d'appels de démarchage, une vraie tranquilité d'esprit.

I had the exact same issue. My nephew would always put the volume at maximum when watching "wheels on the bus" (still haunting me to this day).

So I dived into Apple documentation and iOS settings, but there were simply NO option to limit the volume on iOS.
There are only options to set maximum decibel, or things like that but nothing was working to limit the device speaker volume. What a shame isn't it ?

So as an iOS developer, I made an app! A very simple yet useful tool to cap the volume of your kid's iPad or iPhone.

To this day, I got a lot of downloads and it is helping a lot of parents that have children dealing with Asperger, autism, adhd…

Here is the app, available on iPhone and iPad.

You just have to install it, enable the limit, and define the maximum volume and voilà, you're done and you can get your ears back.

Please note that you have to keep the app open in background for the limit to work. It should not be an issue though. You can also setup a pin code so your kid can't turn off the limit!

No more headache, relax and enjoy !

“Oh, but I’ll need a web server, and a database, and hosting…”

Say no more, I have the solution you need (and I’ve already implemented it in production). I’m going to assume you already know how to develop an iOS application, and you just lack the back-end knowledge.

A few months ago, I wanted to create an online mobile game for iOS. Players needed to compete online, so a server was essential.

I considered the available solutions for creating a back-end for my game. I researched several options: “Backend as a Service”, custom back-end with Node.js, using CloudKit, hiring a back-end developer…

None of these solutions fit: they were either too complex or too expensive. That’s when I stumbled upon the Swift Vapor framework.

Vapor is a web framework written in Swift, designed for building web applications and RESTful APIs. Being fully in Swift, it offers iOS developers a smooth transition from mobile development to web development. Vapor allows you to build efficient web applications while retaining the security and speed of Swift.

For me, it was the perfect compromise. Vapor enables any Swift developer to craft a web application that can act as a back-end by offering a REST API, microservices, and all with relative ease. Currently, Vapor 4 supports structured concurrency with async/await, greatly simplifying code implementation.

As a Swift developer, you must use Swift packages everyday. The great (magic?) thing about Vapor is that it allows you to share code between the server and the client. This is a real banger in the world of iOS development. You can share code (API models for examples) by putting them into a Swift package that will be imported by both your iOS app and your server.

Unit tests are getting their part of the cake too, you can test very easily your APIs, check that everything is fine in the database, prepare the DB before tests run. I find the testing part very nice in Vapor and it allows you to have a full test coverage over your server because it is critical for a back-end server to be crash-safe. Of course you can have a testing-only database, defined very easily.
The only thing I found not so great is the implementation of performance tests (there isn't any measurement tools, or more generally any performance tools to check ) unit tests.

"Okay I can create a simple web server, but what if I need to persist data?"

So you need a database for your game? Vapor supports multiple types of databases, don't worry you have all that you need. For example I used SQLite database during development and testing, and switched to a PostgreSQL database (migration was easy) when going to beta-testing and production.

"But I don't know anything about system admin, and I don't know know how to host my server…"

You are worried because you are not a DevOps guy, you don't know much about application deployment on host machines or in the Cloud? Again, Vapor got your back and works perfectly with Docker. Setting up your web application using Docker is simple and is actually well documented in Vapor doc.

Using Docker, deployment on a machine has never been so easy because all you need is a Linux machine. You can just rent a Linux machine in the cloud (On my side, I have used an old computer at my home at first during development and testing, then moved to a Linux droplet in the cloud using DigitalOcean). Note that I was also able to deploy my server using SSL certificates and setup HTTPS with Nginx, thanks to Docker.

"Is this Vapor thing only for small project?"

Vapor is the way to go if you need a back-end for your application and you know Swift. It has a lot of features and a large set of tools for common use cases (Push notifications, Sign in with Apple, Google, Facebook, Database, server APIs, scheduled jobs, and many more). It's perfect for small-medium scale projects, but it can also scale perfectly to large projects with a bigger network loads.
You can easily define a load-balancing system with multiple instances of your application using Nginx.

No excuse left? You now know where to start to building your iOS app, and not only stick to offline productivity tools! ;)
Stay tuned, I will write another post about my feedback after using Vapor for some months, from development to production.

What are your thoughts on Vapor? In my opinion, Vapor gives all iOS developers the power to create an online app from A to Z, without relying on something or someone else.

Now go build something!

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.

One Language, Two Jobs: Building an iOS App & Server Using Swift was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

I won't be introducing and explaining Swift packages, how to create a package and how to link it because you can find this pretty much everywhere starting by the official documentation.

Instead, let's talk about how to actually separate your code into packages, what packages you will have to create, and how to organise them. I will present the packages architecture we have at Dashlane and why it completely fits our needs.

It’s important to remember that the architecture I am illustrating is just a suggestion. Everyone is free to adapt and improve it as per their project’s requirements and needs. Every team and project is different and what works for one may not work for others, even though it's a pretty generic solution. It’s always a good idea to evaluate your options and make the decision that works best for your specific use case.

Package architecture at Dashlane

You can find just below a chart of the current package architecture we use at Dashlane.

Let's dive into the different layers of that architecture, and we'll see the relationships between them right after.

"I see Foundation packages on the first layer..?"

In this layer you will be able to define packages containing code and types that are at the very core level of your application. You will most probably put things that are used everywhere in the application like some business-related types, and common extensions, and database related stuff as models.

Foundation packages can be imported from anywhere in other packages except from other foundation packages.

Example: We have our DashlaneAPI package which contains the autogenerated API models, but also a UIDelight package that contains a lot of Views extensions or view components that are used everywhere.

“Hmm. Foundation packages are like the most common and atomic pieces or our app, I get it. So what is the next layer called Core packages?”

Core packages are able to import Foundation packages. Those packages contains logic and backend code related to something specific in the application. Those packages are independent from each other.

For example we have CoreSession that contains the logic and code related to our users sessions and logins data. CoreSession is able to import DashlaneAPI.

We also have CoreLocalization that contains common localised strings that are used in multiple parts of the application. This packages uses Swiftgen to autogenerate strings by importing a swift plugin.

“So Core packages contains backend and logic, that means the UI will go to Feature packages, right?”

These packages are the higher layer of our architecture. Each package in this layer represents a feature or a group of related features in the application. They encapsulate features and they also contain UI code (all views and viewmodels belong here).

Feature packages can import any foundation package and also any core package. Of course, a feature package cannot import another feature package.

Example : We have our whole login flow contained in a LoginKit package

“Okay, I can see the 3 layers of the architecture, but what is this last block that have arrows pointing everywhere?”

We also have two different Swift plugins, one for Sourcery and one for SwiftGen. When working with packages you can't have build phases like in targets of your application. That is why you can use Swift plugins instead to be able to run scripts at build-time for your packages.

Plugins can be imported and used in any other packages, for example we use SwiftGen in CoreLocalization to autogenerate strings from the translation files.

“What are the relationships between the layers?”

As you can see on the chart, there are a few rules we must follow when developing in packages.

• A feature package can import everything except other feature packages
• A core package can only import foundation packages
• A foundation package can't import other package
• Swift plugins can be imported/used by any other package

“Do you have naming convention for packages?”

We decided to name every core package "CoreSomething" and every feature package "SomethingKit". This way, it's easy for a developer to know if he is able to use that package or not, and what kind of API he would expect to see in it.

“Do you have an example of one dependencies graph from the feature layer to the core layer ?”

As you can see, even when you have a lot of packages, the graph is still readable, and we can clearly see the layers. I voluntarily excluded Swift plugins from this graph and external packages since they are not considered in the architecture.

“Why would I use this project architecture?”

Let's start by seeing why using swift packages is very useful. In fact, using swift packages has many benefits.
For example, it clearly improves the code architecture. By creating pacakges we separate our app into different parts and all of these parts can have their own unit tests, UI tests, integration tests… That means we have a better code structure, and can test our code separately by package. The execution time will also be reduced.
Apple also recommends to use Swift packages so if your app respects the best practices, it can maybe make your upload on the AppStore easier?

There is also another major benefit: a Swift package can be easily imported into another project/another app. At Dashlane we have different applications: the Password Manager iOS app, the Authenticator app, and our macOS app. We also have the autofill extension on both iOS and Safari on Mac. By using Swift packages, we are able to write code that is not just well-separated, but also reusable across all our apps very easily ! Without these packages we would have to write a lot of boilerplate and duplicated code across our different apps.

“Okay, Swift packages are interesting, but what are the benefits of this specific packages architecture?”

When starting to work with packages, you can easily end up creating cyclic dependencies (even if Xcode will tell you if you make an obvious mistake in the package definition). At some point you can also question yourself about where to put the code you want to export in a package, because it could fit in multiple places.

What happened also at Dashlane is that before we set up this package architecture, we created a "CommonPackage" that contained a lot of code used everywhere and that we could not easily put somewhere else because it was too dependent from other features/parts of the app. With the time, this package has grown and contained a lot of code. It has finally become the new tote that we were trying to get rid of at the beginning, when creating Swift packages. And believe me, once this spaghetti code is here, it will take a lot of work to clean it. More work than actually do it the proper way directly from the beginning.

By adopting a clear architecture like this one (or similar), when developing you will be forced to put your code into these packages, and sometimes when your code doesn't fit into only one package that means that the code has to be split. It is a good practice to start thinking about the package architecture directly at the beginning of your project or at the moment when you adopt Swift packages, to avoid all those issues that I mentioned earlier.

We also are able to maintain only one repository containing all of the packages by defining them as local Swift packages. Having only one repository is useful and really helps to maintain/evolve the codebase easily. Merge requests have never been so easy to review !

“I get it, using package looks cool, now tell me about the dark side”

Yes, it is very helpful and it can be relatively easy to divide your app into packages, but some cases can get you into trouble. Here is a short list of issues that we have met during our journey into Swift packages :

• Handle links between different packages of the same layer, and avoid cyclic dependencies between packages
• Choose where to develop a feature that is shared across several modules
• Handle assets and code-generation tools in packages (Swiftgen / Sourcery)
• And the most difficult one : handle exportation into packages of an existing massive app which already has many dependencies

I will come across those issues in future posts where I will be able to go a bit deeper.

“What can we say to conclude?”

In conclusion, my feedback on Swift packages is pretty clear. They are useful, they allow to have a decent architecture, and it's a lot easier to develop on this project (with multiple apps) since we started to organise it into packages.

However, even though it has many advantages, creating packages and exporting code into it can lead to some complicated situations and you have to be careful when dealing with packages. By adopting a clear architecture at the beginning you will be able to avoid such situations.

Certainly, the sooner you start to modularize your application, the better. It is more difficult to try to modularize an existing app, and it gets even harder if it’s a big app. So think about it when building a new iOS app!

Stackademic

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us on Twitter(X), LinkedIn, and YouTube.
• Visit Stackademic.com to find out more about how we are democratizing free programming education around the world.

How to Organise Your Swift Packages was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Check in on sunday

When you arrive at the convention center, all the blue shirt people start to clap and cheer. They offer a warm welcome effect during all the way long to the entrance. In fact, pretty much every time you enter a building during this week, you are likely to be acclaimed !

So when I arrived they gave me my badge, a very nice reversible vest (I got the blue one), and some pins. I already heard about those pins, and some developers there were trying to collect them all.

The first Keynote

To fully get in the WWDC spirit, my team and I decided to stand in the line on the very morning of monday. We were there at 4:50 am, and we were absolutely not the first ones ! Some of the people were there since 2:00 am, and maybe even earlier. So we waited until 9:00 am to enter in the conference room, the WWDC staff were trying to make the waiting more fun so the time wasn’t too long.

Then Tim Cook arrived on stage and started the keynote. It was exciting and the way Apple presents their new features is always spectacular so being there in front of Tim Cook while he was talking was a great moment.
I particularly liked the way they introduced the new dark mode on iOS 13.

Craig Federighi is particularly appreciated in the Swift developer world so when he came to present the new iOS 13, there was a lot of applause.
He also is much more accessible than Tim Cook, and I even managed to get a selfie with him !

WWDC App

There is an iOS App called WWDC where you can find all the sessions and labs of the week. All the week planning is released just after the first Keynote, so when we grabbed our (delicious) lunch at the end of the conference, my team and I checked the planning so we could plan our week.

There was 3 main halls for all different conferences, a few smaller rooms, and some places where all the labs were located. The Hall 2 was the largest one, and this is where all the main conferences and the most popular ones (SwiftUI, Dark mode…) took place.

On the WWDC app you could also make an appointment with Apple engineers on the labs for any questions you have. The appointment system is quite good and you receive a notification on your phone when it’s your turn, then you have 5 minutes to get to the lab.

Events

There are some events at the WWDC that worth taking part of. The events that I liked the most were the sportive events : almost every morning of the week, a special event took place. It could be a 5 km run, a HIIT workout, or even a yoga session. I had to register to these events on the app to be able to participate.

Each session would give you a special pin, a colorful wristband and some other gifts (I got a yoga mat and massage balls at the yoga session).

During lunchtime, some special talks were organized in the conference halls. There were some guests that came to tell their successful and inspiring story. For example Chris Downey told how his sudden blindness has impacted his architect life. Dr. Ayanna Howards came to tell her story about her accomplishments since she was hired by NASA to work on a robot for future Mars missions.
These talks were very interesting and that was a great experience to hear from these inspiring people.

The Bash

The traditional Bash takes place every year during the WWDC. It is a kind of festival that takes place near the convention center on thursday. This year The Weezer was invited to perform on stage. It was a really nice event where we could have fun and meet other developers from all over the world.

Labs

During the WWDC you can make appointments with Apple engineers on different subjects, and there are the most likely to answer all your questions about these subjects.

I participated in some labs and here is my feedback : if you have a good understanding of the subject, and already have prepared some specific questions, a talk with an Apple engineer would definitely be interesting.

However, if you just want a overview of the problem, (for example Siri Shortcut with parameters), this is not really interesting, in my opinion.

Even if the lab description say “you can come if you don’t have any specific question and you want an overview”, I don’t think engineers are there to give you that overview. They are more likely to ask you “what do you want to know exactly ?”.
In my case I didn’t knew the technical details about Siri Shortcut and I didn’t even knew what to ask. The engineer was nice but the appointment last about 5 minutes and since I didn’t had any specific questions (except one bug that he couldn’t help me with, he just told me to open an issue on this).

On the other hand I went to the Swift packages lab and ask questions about packages and frameworks and since I am more comfortable with this, the appointment was very interesting and the engineer answered most of my questions with precision.

So I think these labs can be interesting but you have to know a minimum the technical details of the subject you are seeking help.

San Jose

San Jose is not a big city and except the McEnery Convention Center where the WWDC takes place, there isn’t so much to visit, or even for going out in the evening. Most of the bars close at 10 pm and if you want to eat in a restaurant, you better have to arrive early.

Concerning the housing market, both hotels and airbnbs are extremely expensive, overall during this week of the year. For example the Mariott placed just in front of the McEnery Convention Center was about $600/night minimum.

San Francisco looks much more interesting for visiting and going out but is at one hour’s drive from there (without traffic) so it’s not easy to go to San Francisco after the conferences, then come back to San Jose.

Conclusion

In my opinion, having the chance (or the privilege) to attend this global event is really an opportunity that anybody should not miss. The WWDC is a unique kind of event and as an iOS developer I think it is really a good thing to go there at least once.

Even if most of the conferences can be viewed online from anywhere, and if all the labs are maybe not that interesting, this event has the advantage of being global and unique. That means developers from all over the world come at this place at this time of the year. This is a place where you can have a conversation with americans, germans and french people at the same table while having lunch, and then sit between a russian and an indian during the following conference.

This is the best place to make contact and to talk with developers who have different cultures, different work process, different points of view.

To conclude, I would say that going to WWDC at least once is a must for any iOS developer.

“I want to export that part of my app but it’s tied to the rest of the app like a spaghetti plate !”

When I was starting to modularize a part of the app I was working on, I ran into a wall.

I wanted to export a service (in fact it was the Tracking service) into a separate framework. The problem was that this service was too hardly tied to the app. It was using an other service which was itself using another deeply anchored in the app.

In order to export the tracking service, I would have had to refactor and remake the whole set of service in the new framework !

But the fact is I didn’t had the time to do this and regression testing would have been a nightmare, and for many other reasons that you could have in any company (process, budget, deadline).
So I had to find out how to export this part of my app without refactoring everything.

Let’s start with an concrete example !

Here we are, the best way to learn and to understand how things work is to practice ! (I am going to provide the Github repo for this example at the end of this post)
So let me set the context, we have a small app with only 2 screens :

• A home screen
• A payment screen (we want to export that screen into a framework)

The payment page contains a TextField to enter a card number, and a Pay button. When you press the button, the payment should be launched.
But ! The challenge resides in the payment method. Let’s suppose we just can’t export the payment service for some reasons I evoked a bit earlier.

So we have these two screens, declared in two different targets. The home screen is declared in the main app target, and the payment screen is declared in another module called PaymentModule. We also have a PaymentService declared in the main app target, as follow :

The pay method is the method we can’t extract from the app because it is too dependent. But we want to use it from the payment module.

We have a PaymentViewController defined in the Payment module, if we try to call PaymentService we will have an error since this service is not in the module. You can’t import the main target within a module (that would be a nonsense)

So how are we going to use this method from the PaymentViewController ?

Define a protocol in the module

This is going to be our bridge. You must define a protocol in the module with a method describing what you want to use in the main app target.

So let’s define a protocol named PaymentServiceProtocol with a method pay :

Implementing the protocol in the app

Now we have to tell to our PaymentService to conform to this protocol. We just need to add this :

“Why the method declared in the protocol is not implemented in this extension ?”

You are right, when conforming to a protocol you must implement its properties and methods. The trick here is that the method name in the protocol is exactly the same as the method name in the PaymentService we declared a bit earlier. In that way, the system will know it will have to use the method pay declared in the PaymentService class when accessing the protocol method.

Linking the two parts

We must now join the two parts together.
From the HomeViewController, when we tap on the “Go to payment page” button, we are instantiating a PaymentViewController. At that time, we are going to pass it a reference to the PaymentService class, but the payment controller in the module will see it as a PaymentServiceProtocol type.

Here is the trick :

We are passing PaymentService.self and the code in the module is seeing a PaymentServiceProtocol.Type.
Now we can use call the pay method defined in the app from the module !

Using the bridge

It is now very easy to use the bridge we created :

The method didTapPayButton is called whenever you tap on the Pay button (sounds correct, right?). Check on line 23 : we are calling the pay method on the protocol reference we got from the app.

Since the PaymentService conforms to this protocol, the system will execute the code inside the method pay , which is defined in the PaymentService.swift.

In other words, we are using the method that we couldn’t call from the module at the beginning ! The bridge is now set.

Here is what it looks like when you tap on the pay button.

Conclusion

To conclude, this bridging method can be used if you want to export a component of your app into a framework.

This technique will allow you to cut the noodle out of the bowl, if you are forced to export that part of your app into a framework but you can’t export the whole thing, for any reason you could have.

I think this a temporary solution, before getting out the whole component inside the framework, when you will have the time for example. (In this scenario, someday you will have to export the pay method inside the Payment module)

I admit that in a ideal world, with unicorns and fancy stuff, we would not do something like that. We would rather export the whole component, but as I said many times this is not always possible.

You can find the Github repo of this project here, don’t hesitate to check how the bridge is done and to try it by yourself.
I hope this post can help, feel free to ask any question you have in mind !

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +442,678 people.

Subscribe to receive our top stories here.

How to create bridges between frameworks in an iOS app was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article will mostly cover encapsulation, circular dependencies, images (bundle), pbxproj and extraction of existing app part to a framework.

“Okay so where am I going to create this ?”

When you have frameworks in your app, the first question that may come into your mind is “Where are you going to write code for this next feature ?”.

As I said in my previous post on frameworks, you should categorize your frameworks. You could have one Core framework, some feature-specific frameworks, and some other technical frameworks.
If your new feature or whatever you are going to develop doesn’t enter in any existing framework, you might want to create a new one.

Make your choice carefully because it will surely have impacts later if you want to change or interact with this new feature.

“Public, internal, private ?”

You will have this popping up in front of your nose ! This is because you need to declare your classes/structs or whatever you are defining in your module and want to access it from the outside as public.

When developing an app without framework, you usually don’t pay much attention to visibility or access control because everything in Swift is by default internal. Internal means that you can access it in the current module. When you are developing a module, you need to explicitly define the class you want to be usable from the outside as public.

This also forces you to have a better code encapsulation and to better define your app structure. You should only mark as public the types that you want to be accessible from the outside of the framework. Everything else should be at least internal, or even private if it’s for a local use.

So if you want to silence the Xcode error just mark your class as public.

“Let’s import this framework everywhere we need it !”

Yes, but ! When working with frameworks you have to be careful or you will deal with circular dependencies and many headaches. Inside your framework, you cannot import a second framework which is already importing the first one, directly or indirectly.

Also, you may have a situation where a feature framework (let’s say Account) want to know something about another framework (Booking) to create a link. For example you want to launch a booking search based on your preferences in your account section. From the account framework you want to launch a search so you may want to import Booking framework, but that would be wrong because it would be questioning the separation of these two frameworks.

So how to handle links between two frameworks that shouldn’t import each other ? This case is an interesting question and one solution is to create a bridge between the two frameworks, using a pattern known as POP (Protocol Oriented Programming).

This solution requires a long post to be explained so I am not going to discuss it here but I surely will in another article.

“My app crashes when loading an image !”

This is going to get you into trouble if you are extracting an existing part of your app with many images. Each framework has it own bundle, that means if you put your images into your framework.xcassets and load your images normally, in your .xib or .storyboard or even using #imageLiteral, you are eventually going to have a crash like below :

The app is crashing because the bundle used by xibs, storyboards or imageLiterals is the main bundle. Since you are developing in a framework which has its own bundle, the system is looking for the image asset in the wrong bundle.

To resolve this problem, you have to specify the bundle for every image you use in this framework. Here is an exemple of what you can do :

Here you are creating a class inside the module, just to indicate to the Bundle init on line 6 that you want to use the bundle of that class, which is the framework bundle. By defining this Bundle extension, you can create an image located in the framework bundle by specifying it very easily.

Concerning xibs and storyboard I think you should set image sources in the code, because it is safer.
If you are creating a new module and don’t have any existing image, don’t forget to specify the bundle for your new images.

“I want to export a part of my app but the dependency is too strong”

When I was starting to modularize a part of the app I was working on, I ran into a wall. I was trying to export a little service, which was in fact using another service, which depended on another one… and so on.

It was not possible to export all of these services to my new framework because of the dependencies. It was too tied to the main app, like if you were trying to get a noodle out of a noodle dish, but end lifting the whole thing.

So then I had to find out how to export my first service without grabbing the whole noodle dish.

I am going to explain in details how I managed to do this in another post, since it requires a clear explanation, and can be a little too long for this post.

“Conflits on pbxproj… a pain in the neck !”

Yes it is ! If you are multiple developers working on the project, you will be confronted to this hell. Unfortunately, I don’t have any miracle solution for this problem.

Each time you create a new framework or move files to other targets, or basically everytime you touch on the configuration of one target, you are modifying the .pbxproj file. That means you are going to have conflicts with your team mates and this file is very hard to read. Often you will have to “choose both” but you surely will have to check if the project is broken or not.

However, there is a tool called XcodeGen that could be a solution to this problem. You can read more about it here.

To conclude, I don’t have any real solution for this problem but keep in mind that the number of conflicts on this file is important only at the beginning of your framework structure creation. Once you have your frameworks defined, everything should work fine and you will no longer have this nightmare with you !

You can check the GitHub project, showing a modularized iOS app, basic problems I came across in this post, and how to handle them (images and bundles for example).

I hope this post could have given you an overview of the main problems that you could encounter when modularizing an iOS app. All of these problems can be overcome so keep going ! ;)

Who else can relate ? That’s the most frustrating feeling when you only need to change a single line in your code and then the whole app compilation starts over… and can take up to loooong minutes !

As your iOS app is getting bigger and bigger, the compile time is growing too ! This is the first reason why I started to look at frameworks.

By default, you only have one target for your app, and possibly other targets for unit testing, and UI testing. But if your app is developed on one single target, when you change one line of your code, Xcode will eventually rebuild the whole app, depending on which file you changed, and what data you changed (variable name, access control, string content…).

But if you came to read this article, you may know how annoying it is to wait 5, 10 or even 15 minutes for the app to compile (if you are working on a big project). This problem is even more important when you are many developers working on the app : the waiting time is multiplied by the number of developer. In that way, you are wasting a lot of time and your efficiency is considerably reduced.

This is a very common problem on big apps and I think the way it should be solved is by dividing the app into different frameworks.

“What exactly are these frameworks ?!”

You’re right I haven’t defined it yet. So frameworks are parts of the projects that can be built separately and they have their own target. In this article I may call them “modules”.
You can manage to not only build, but also run a module by creating a sample app that import only the framework concerned, and using the features contained in the module.
Therefore, when you are changing the code of a framework, only this framework will be rebuilt at the next compilation, because other frameworks and targets haven’t changed. This is where a precious time is saved.

In fact, creating frameworks has many other benefits.
For example, it clearly improves your code architecture. By creating modules you separate your app into different parts and all of these parts can have their own unit test target, and UI test target ! That means you have a better code structure, and can test your code by framework. We all know that the more separated the code is, the better.
Apple recommends to create frameworks so if your app respects these best practices, maybe it can make your upload on the AppStore easier ?
There is also another benefit : a framework can be imported into another project.

Now you want to create frameworks ! In addition to all of these benefits, Apple made it very easy for us to create frameworks within Xcode. Just go onto “File -> New -> Target” and choose Cocoa Touch Framework, as shown below. Your new framework will be displayed in the target list. Here I have also created the unit test target for my framework.

You may want your framework to depend on another one. For example your CustomerAccount framework may need the Network framework for all network management. To make a framework depend on another one, you will need to check the target scheme. In the build tab, add the module. You will need to add this module in the build phases of the parent target too.

“What frameworks should I define ?”

That’s an interesting question, and I think it can have multiple answers. On the project I am working on, we chose to divide modules into two different categories :

• Feature modules : Modules that represent a feature of your app. For example, you could create a module Account for your customer account part.
• Kit modules : Modules that represent a technical part of your app. You could have for instance a Network modules which handles the networking layer, a UIComponent module representing the UI elements of your app, a Localization module for your wordings… You can eventually create a Core module for everything that is connected to many parts of your application and is too hard to isolate.
  If you have a local database, maybe a Storage module could be convenient to handle the database requests.

A feature module should obviously import one or more kit modules. A Kit module should NOT import a feature module. And a feature module should not import another feature module.

“Creating frameworks is so helpful and easy, what’s hiding behind it ?”

Yes, it is very helpful and it can be easy to divide your app into frameworks, but some cases can get you into trouble. Here is a short list of problems that I have encountered during the modularization of the app I am currently working on :

• Handle links between different modules
• Avoid cyclic dependencies between modules
• Choose where to develop a feature that is shared across several modules
• Handle images between all different bundles
• And the most difficult one : handle exportation into frameworks of an existing massive app which already has many dependencies

I come across all these problems in detail in this medium post, because some cases need a concrete example.

“ What can we say in a few words to conclude ? “

In conclusion, my feedback on this modularization process that I came across on my project is pretty clear. Frameworks are useful, they allow to have a decent architecture, and I really prefer to develop on this project since it has started to become modularized.

However, even though it has many advantages, this process can lead to some complicated situations and you have to be careful when dealing with modules.
Certainly, the sooner you start to modularize your application, the better. It is more difficult to try to modularize an existing app, and it gets even harder if it’s a big app. So think about it when building a new iOS app !

You can check the github project, showing an iOS app modularization, how to use pods inside your modules.

If you want to learn more about the common problems you could encounter when modularizing your app, check my post dedicated to it !

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +440,678 people.

Subscribe to receive our top stories here.

Modularize an iOS application was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.