T1 will always be the province of the universal app, so we would not support a specific platforms UI. We would want your app to look the same across all devices for consistency of experience. That said, there have been calls/requests for platform specific T1 command sets but we'll chat about that again once AppGameKit is a little more established.
You can of course do pretty much what you like in T2 C++, including using the iOS GUI from the SDK. Mix and match as you see fit. In fact, one of our top coding bods, Mike, added AdMob in one day to a T2 C++ natively compiled app and it's now selling on the App Store. Download it and see the adverts at the base of the screen at:
http://itunes.apple.com/gb/app/snake-snacker/id459426689?mt=8
Also, if you are insistent on going uber C++, and don't mind deviating from the T1 style of coding, then AppGameKit also exposes it's OOP classes for you to inherit from, such as:
agk::sSprite *pSprite = new agk::sSprite;
pSprite->SetPosition ( x, y );
I personally avoid recommending this approach as down the line we might introduce a fancy cross compiler which can take your T1 and convert it to T2 (and vice versa), but such a converter would find the above two lines very tricky to convert. I would always recommend the more traditional AppGameKit style, not least because it's a little easier to read:
agk::CreateSprite ( 1 );
agk::SetSpritePosition ( 1, x, y );
We created T2 C++ so you can have as little or as much control over your app code as you wish, without forcing you down a single path that might not suit your preference or time frame.
I drink tea, and in my spare time I write software.
