iOS engineer who worked on the Fabric app here :) I gave a talk about this topic at a Swift conference last year, if you wanna check that out! https://www.youtube.com/watch?v=Ent6LJDIB3I
hi, thanks for sharing. one question though : to me, the hardest and most convoluted api in cocoa isn't related to model handling but to the view : doing simple things like a tableview reload immediately followed by a scroll, or animation composition when updating data always is a problem because the way uikit elements work internaly is quite opaque ( and the fact that there are three orthogonal api to position a view don't help).
So the fact that reactive cocoa tries to hide the notion of state transition makes me wonder how you can then deal with UIKit views animations api ( collection flow animations or tableview begin updates, no to mention view controllers interactive transitions).
I've wondered if using a future based api for view animations wouldn't be a solution..
Maybe you can answer who was the person that decided that your library was so special that you have to use a damn application to add it to a project, rather than use the same exact procedures to add a library that every other library uses? No, I don't want to use your application to add the library, and no, I don't want to have to go through the onboarding every single time I need to add it or update it.
i was really hesitant when i saw how fabric is supposed to be installed, using a mac app, but i've got to admit that it's a really pleasant experience so far.
So the fact that reactive cocoa tries to hide the notion of state transition makes me wonder how you can then deal with UIKit views animations api ( collection flow animations or tableview begin updates, no to mention view controllers interactive transitions).
I've wondered if using a future based api for view animations wouldn't be a solution..