[e28eta]

I've long thought that UIKit (and supporting frameworks) need a simplified API. I also believe that the best "bang-for-buck" for developers is learning the platform APIs, not third party wrappers, since that's the most transferable skill. How do you balance those competing interests?

[postfl]

This is a great point. One of our main goals with the project is to keep the api as similar to its underlying language as possible. We did this for the ObjC version, and now for Swift as well, meaning that for anyone learning C4 they’re actually learning Swift. However, there are certain points where simplifying will make changes to the language, and in those cases we’ve taken care to make sure that those changes are both modern and also reduce a lot of overhead for the developer.

Our goal is to have C4 make life easier for people: 1) those who are interested in learning UIKit can start with C4 and dig into its open-source base to gain more transferable skills, 2) those who are not interested in learning UIKit or transferable skills but just want to put something together fast, 3) people who already know UIKit / Core Animation but don’t want to deal with some of the complexity.

[fit2rule]

I've been taking a different approach for the last few years, building apps in MOAI, which is basically "like Java, but you get to/have to be a native host developer as well".

MOAI is a cross-platform Game-engine/GUI-toolkit designed tot allow pretty fast depiction of games/GUI interfaces, specifically game-like interfaces. It is very easy to get a working game environment, of most of the most common forms, in 20 or 30 lines of code in MOAI, i.e. Pong, jump'n'run, shooter, etc.

On top of that, there are already 3rd-party frameworks which implement some sets of standardized "GUI" basics like sliders and buttons and scrolling scenes, and so on. So its possible to do a common GUI that runs exactly the same on all platforms - i.e. ignore native entirely and boldly forge ones own ecosystem of standards.

Which is actually kind of nice, to be honest.

So I'm wondering about the C4 side of things and your plans to embrace/wrap/extend the GUI world. Will you be a subscriber to the native world - and thus either have to do a lot of native host code (or find some way to make your developer-users responsible for the problem) - or do you think there is a future in non-native/runs-everywhere GUI development beyond that provided 'by the majors'?

I'm going to put C4 on the lab-bench some time in the next few days, looking forward to checking it out ..

[postfl]

Being platform-independent is definitely a major feature that we’ve had discussions about over the last year. Ideally, yes, we want C4 to go beyond simply an API for designing interactions, exploring and building apps for iOS. We’re hopeful – with Swift now being open-source – that it will be ported onto other systems, and if that’s the case then we see a lot of potential for being able to have C4 be part of that movement. How that pans out is still unclear, but even in the shift from ObjC to Swift we’ve started to make attempts to abstract our API in ways that would allow us to make the jump to cross-platform more easily.

I definitely think there’s a future for non-native, but right now the lock on hardware drives the current climate of software development (for mobile). The current animation/media/interaction core of C4 is just a first step towards a lot of other integrations, add ons and components that we want to build out. So, for now I’m a subscriber to native because I think that it’s still a lot of work to build out C4 to something mature and stable for a single platform.

> Looking forward to hearing your experiences with using C4 for the first time.