Chris Eidhof of objc.io put some experimental code on GitHub where quite a few Cocoa view components are contained by classes he owns himself. The AppDelegate is super instructive: Your Cocoa app needs an NSApplicationDelegate. But it doesn’t have to do anything except route events to the proper collaborators. Still it’s the first object we usually put logic in only to (hopefully) refactor it out later.
One thing that repeatedly messes up the conceptual purity of a view model is figuring out which entity should be mutated upon user interaction. Part of this purity stems from the fact that a view model is best served as view data to stress that it doesn’t contain much (business) logic. Making the data mutable introduces a lot of problems figuring out what that view model really is.
One of the commenters nailed it: any MV* variant focuses on architecting view components. Only VIPER takes the application as a whole into account. MVC by itself is an architectural pattern, but not an approach to app architecture in itself.
A UIViewController belongs into the user interface layer and is, in fact, a composite view itself. That’s confusing at first because of the name. This insight will liberate you from thinking that a view controller is sufficient to glue data to UIKit components. There’s room for a whole application between these two.
The VIPER example is exceptionally good. It takes VIPER’s heritage of Clean Architecture and Hexagonal into account and defines the Interactor through an output port. In that way Bohdan’s sample code is more east-oriented and cleaner than what you’d usually find on the topic:
protocolGreetingProvider{funcprovideGreetingData()}protocolGreetingOutput:class{funcreceiveGreetingData(greetingData:GreetingData)}classGreetingInteractor:GreetingProvider{weakvaroutput:GreetingOutput!funcprovideGreetingData(){letperson=Person(firstName:"David",lastName:"Blaine")// usually comes from data access layerletsubject=person.firstName+" "+person.lastNameletgreeting=GreetingData(greeting:"Hello",subject:subject)self.output.receiveGreetingData(greeting)}}
Usually, you’d model provideGreetingData() as a function that returns the data to the caller. This will cause trouble in async processes of course.
You see in the full example that the amount of types seem to explode. Don’t be afraid of that as long as you can assign each type a specific responsibility. Then it won’t turn into the mess everyone seems to be afraid of.
Having used VIPER in apps myself, I see a problem with the names, though. XYZInteractor and XYZPresenter aren’t much better than XYZController in terms of expressiveness. On top of that, a concrete Presenter is always modelled to act as event handler, too. Don’t let this fool you into thinking you absolutely have to do this yourself – there’s always room to separate writing from reading operations, or event handling from view population.
Shaving off VAT and then again 30% for Apple for every purchase of your app in the Mac App Store can be madness: the only real benefit is that people know how to operate the store. But if you’re just starting to run your business, discoverability is hardly a feature.
Instead of drowning in the warehouse that the app store is, put your software in your own store. You have to build an audience anyway to get started. So stay in touch with them. Know your customers. And stop giving away 30% for a promise that doesn’t hold.
Save days of research and implement the techniques today
Copy & paste Swift 2.0 code to integrate into your app in <1 hour
Utilize in-app purchase of licenses for a higher conversion instantly
2 fully functional sample applications, including a time-based trial app
Secure license code generation and verification included
This book will save you hours of research and days of fiddling with SDKs. It shows you how to set up products for sale on FastSpring including automatic license code generation and then guides you through the process of adding license verification to your app.
Don’t need all the explanations? Just follow the setup steps and copy the code into your project and you’re ready to roll in half an hour!
I’m not affiliated with FastSpring. I just think their service is awesome.
Here’s what FastSpring’s CTO Mike Smith has to say about the book:
We appreciate Christian’s efforts in creating a guide that enables Mac developers to sell applications through FastSpring’s award-winning e-commerce platform. He has provided detailed instructions to help developers configure key elements of their online sales process. The spirit of community captured in his book reflects FastSpring’s mission to connect people globally in the digital economy.
I truly believe in the spirit of community and I believe you can make it as a developer without the App Store. This book is here to empower you so you don’t have to figure out all the scary details.
So many other indies rely on FastSpring, too, including:
Smile Software (TextExpander, PDFpen)
Realmac Software (Clear, RapidWeaver)
Tyler Hall (VirtualHostX)
Ironic Software (Yep, Leap)
Bohemian Coding (Sketch)
toketaWare (iThoughtsX)
well, and me, obviously :)
Get to know their stories from this book. Be inspired and take the leap.
Because I think it’s so worth your time as a Mac developer, get it for 25% off until Christmas when you buy from my store.
Yelp reuses a setup of modular table views across their huge app. A simple timeline entry can be composed of 5 cells, each with its own model representation. These cells are used to create various component setups. What I find most interesting is the combination of registering cells for reuse identifiers in one place and using reuseIdentifierForCellAtIndexPath in another.
In a top secret project I am working on, I think I found a consistent way to create UITableViewControllers in a reusable fashion without making a mess with massive view controllers. The key ingredient is, as always, delegation from the view controller and thus composing larger components: