I'm one of the author of the framework :) please let me know if you like our approach to apps development we internally use it for creating our own apps at Bending Spoons ( http://bendingspoons.com )
This is great! Is there a way to use with an existing project?
Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
21–30 of 54 posts
Re: Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
#22Earlier quoted context omitted.
I recently worked on an app that adopted a similar framework (ReSwift) and I hated it for the same reasons you are skeptical. It was needlessly complex, horrible to try and debug, and was incompatible with the "status-quo" of standard app development practices. At the end of the day it was just a bad replacement for Core Data / Realm / whatever. I wish I could tell you more but like yourself I really had absolutely n…
RxSwift are super callback objects. I don't know why you would compare it with storage libraries.
ReSwift is a unidirectional data flow library that brings Redux-like behavior to Swift. RxSwift is not the same thing. :)
Re: Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
#23This feels a bit like a solution without a problem, or maybe more like a giant sledgehammer-sized solution to 10 or 15 smaller ant-size problems. I guess I'm just not sure what advantage I'd get by taking a (frankly) mind-bending approach to building an iOS app instead of following normal iOS conventions. And just to be clear I've done React development on the web, and I've thoroughly enjoyed it. Modern web developme…
I think a big problem in standard iOS land is not doing shit on the main thread. It's too easy and after a while you accumulate small bits of main thread cruft, especially as your team / code size grows bigger. It's a similar problem that AsyncDisplayKit was trying to solve, who's ideas later moved into the react world in general. Another general design problem in iOS land is the MVC (massive view controller). View c…
I mostly agree (though I think massive view controllers are a code quality/poor developer discipline issue).
I've seen nothing in React's (or Katana's) architecture that avoids doing things on the main thread when you shouldn't. I'd also argue that GCD offers a nice, elegant approach to not doing things on the main thread when you shouldn't.
But I'd say that MVC-discipline and thread-discipline are baseline skills that I'd expect from competent iOS devs.
RE: dependency management/unit testing, that's an area I agree needs improvement in general for iOS (though I do not see anything in Katana that significantly helps with that). Swinject (as one example) is alright. I'm not hugely impressed.
Re: Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
#24Earlier quoted context omitted.
How do you know it halved your development time? Do you have metrics from projects executed using standard iOS conventions vs. projects using the Katana approach? Or, asked another way, what - specifically - about this approach halved your development time? In my experience, state management hasn't really been a bottleneck in iOS development, at least not to the point where it could account for half the effort of a p…
I don't blame you for being skeptical. The main advantages we've noticed using this pattern are: 1) every time there is a crash or a problem we can look at the the state and the actions that lead to that situation. This improved our ability to spot and fix bugs. 2) we can easly reproduce any appearance of the UI by providing a struct the rappresents the state of the app. This has improved our ability to QA the entire…
Those are legitimately interesting advantages - thank you for replying. Those would make really interesting deep dives blog posts / videos for making a case for Katana.
Re: Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
#25This feels a bit like a solution without a problem, or maybe more like a giant sledgehammer-sized solution to 10 or 15 smaller ant-size problems. I guess I'm just not sure what advantage I'd get by taking a (frankly) mind-bending approach to building an iOS app instead of following normal iOS conventions. And just to be clear I've done React development on the web, and I've thoroughly enjoyed it. Modern web developme…
I've been working with and on a project that uses a similar architecture. At least, it's using a Redux-like dataflow borrowed from ReSwift; views are standard iOS.
The benefits I've seen so far:
- Swift's type safety means you can validate at the type level that your app state is correct. As in, you could have an enum with separate cases for your authenticated and unauthenticated states, instead of optional values to indicate what state you're in. This makes your state stronger, in that the types hold only valid states rather than some possible states being invalid (e.g. unauthenticated with non-nil user info).
- State transitions -- reducer methods, (state,action) -> state -- are purely functional which makes (IMHO) feature work straightforward, testing trivial, and debugging fairly easy.
- Your view controllers become super dumb. All they have to do is render the data and relay input events. This is a nice clean separation of concerns.
- If your navigation route is managed in state, you get deep linking "for free". This is especially helpful in one of our apps for handling global errors that could occur on any network request (update state, route to error).
- Every bit of code has an easily identifiable home.
- Communicating between view controllers is simple. Rather than "passing the baton" as state is accumulated (say a multistep form), state accumulates naturally in the store.
I'm working on combining ReSwift with app coordinators here: https://github.com/willowtreeapps/cordux
I've written about it a little bit here: http://willowtreeapps.com/blog/app-coordinators-and-redux-on...
All that said, I still consider this an experiment. We've written about 40-50k lines of Swift across two apps with 8 developers so far, and opinions are mixed between considering it excellent and considering it burdensome.
Re: Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
#26Earlier quoted context omitted.
I think a big problem in standard iOS land is not doing shit on the main thread. It's too easy and after a while you accumulate small bits of main thread cruft, especially as your team / code size grows bigger. It's a similar problem that AsyncDisplayKit was trying to solve, who's ideas later moved into the react world in general. Another general design problem in iOS land is the MVC (massive view controller). View c…
I mostly agree (though I think massive view controllers are a code quality/poor developer discipline issue). I've seen nothing in React's (or Katana's) architecture that avoids doing things on the main thread when you shouldn't. I'd also argue that GCD offers a nice, elegant approach to not doing things on the main thread when you shouldn't. But I'd say that MVC-discipline and thread-discipline are baseline skills th…
(though I think massive view controllers are a code quality/poor developer discipline issue)
After almost 4 decades, I'd like to think that the "programming field" would finally get the clue and realize that "massive view controllers" are the result of powerful short term incentives. (MVC was popularized by Smalltalk, and "massive view controller" was a problem even then.)
Remember, if you are a genius being outsmarted by laziness, something is seriously wrong -- the other side is putting in so much less effort!
Re: Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
#27This feels a bit like a solution without a problem, or maybe more like a giant sledgehammer-sized solution to 10 or 15 smaller ant-size problems. I guess I'm just not sure what advantage I'd get by taking a (frankly) mind-bending approach to building an iOS app instead of following normal iOS conventions. And just to be clear I've done React development on the web, and I've thoroughly enjoyed it. Modern web developme…
I recently worked on an app that adopted a similar framework (ReSwift) and I hated it for the same reasons you are skeptical. It was needlessly complex, horrible to try and debug, and was incompatible with the "status-quo" of standard app development practices. At the end of the day it was just a bad replacement for Core Data / Realm / whatever. I wish I could tell you more but like yourself I really had absolutely n…
I've been working on an app that's more or less using ReSwift (I've hacked on it a bit). Can you elaborate on what you ran into that was complex/horrible?
Re: Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
#28Earlier quoted context omitted.
How do you know it halved your development time? Do you have metrics from projects executed using standard iOS conventions vs. projects using the Katana approach? Or, asked another way, what - specifically - about this approach halved your development time? In my experience, state management hasn't really been a bottleneck in iOS development, at least not to the point where it could account for half the effort of a p…
I don't blame you for being skeptical. The main advantages we've noticed using this pattern are: 1) every time there is a crash or a problem we can look at the the state and the actions that lead to that situation. This improved our ability to spot and fix bugs. 2) we can easly reproduce any appearance of the UI by providing a struct the rappresents the state of the app. This has improved our ability to QA the entire…
Hi lucaquerella. I've been working on a similar bit (minus the React-inspired UI) here (combining ReSwift with app coordinators): https://github.com/willowtreeapps/cordux
We've also found reproducing the UI via state to be a huge win. We're using FBSnapshotTestCase to generate snapshots of our app across different controllers with different states, automated to take snapshots on different devices and in different orientations.
Glad to see other people are pursuing these ideas!
Re: Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
#29Earlier quoted context omitted.
What are the normal iOS conventions? MVC pattern in iOS usually creates Massive View Controllers that are really hard to maintain and test.
I'd argue that "massive view controllers" aren't "normal", and if you find yourself in situations with massive view controllers, those are likely excellent candidates to refactor into smaller view controllers that can be composed together using something like iOS view controller containment. Well-disciplined iOS developers can keep this under control. I'll turn the question around - don't you see the potential for th…
That is one of the most common complaints about iOS.
Unidirectional data flow greatly reduce complexity because you don't to reason about several places making changes of the state.
I'm programming Elm after 3 years of iOS and, man, it's great. The amount of code I'm reasoning about is always contained in a in single vim window. It's something that can be done in iOS, but it would require very high discipline. In Elm it came naturally.
Re: Katana – Modern Swift framework for creating iOS apps, inspired by React/Redux
#30Earlier quoted context omitted.
I recently worked on an app that adopted a similar framework (ReSwift) and I hated it for the same reasons you are skeptical. It was needlessly complex, horrible to try and debug, and was incompatible with the "status-quo" of standard app development practices. At the end of the day it was just a bad replacement for Core Data / Realm / whatever. I wish I could tell you more but like yourself I really had absolutely n…
I've been working on an app that's more or less using ReSwift (I've hacked on it a bit). Can you elaborate on what you ran into that was complex/horrible?
I couldn't fix a lot of UI problems because when trying to trace what was happening through this system of actions and states I could only find when these bugs occurred when stepping between lines of machine code.
I can't offer a fair point of view because I don't think the project I was working on made proper use of ReSwift. It was very difficult to follow the flow of data and understand why certain things wouldn't work.