In the screenshot below, you can see the toolbar on the bottom. In this example, it's using icons.
![]() |
Toolbar with Icons |
Notice that the the left-most button looks unusual. That's because iOS controls support styles. In this example we have applied a style to that button in the toolbar. We have also applied a style to the titlebar to make it green. Notice the First and Done buttons in the screenshot above? We've got navigation working as well.
If you've ever used the Mail or Settings apps on the iPad, you know that they looks a bit different from the iPhone. On the iPhone you start with a list, select an item and then view the details in another layout that slides over the list. On the iPad, however, the list and detail views are displayed at the same time (at least when the iPad is held in landscape orientation). This is accomplished with a control called a splitview. It essentially holds two layouts. This makes it easy to take the two layouts you would use for your iPhone app and use them with a splitview to create the iPad version:
The above example shows two simple layouts (called "views") that have been dragged into a splitview control. Notice that the titlebar of View2 has been styled not only with a different color but with a different font as well. In most cases you won't need or want to change the look with a style but it supports them if you need them.
Unlike most iOS development tools, we are using native controls. We've noticed others that appear to be using native controls but really, they are just drawing controls that look like native controls. The difference in this case is not skin deep. Native controls, like on the desktop, have automatic features (such as accessibility) that you get essentially for free by using them. And should Apple decide to change the look and feel of the native controls, you get those changes for free. Drawing the controls rather than using the native controls might be faster for the tool developer but it's not the what's best for the application developer or their users.
If you want to get a head start on learning about iOS development, come to the Real Studio Developer Conference. We have several iOS-specific sessions planned so you can learn all the details and start planning your iOS projects.
Stay tuned. We will have another update on iOS soon.
23 comments:
This is a great update, thanks.
"Unlike most iOS development tools, we are using native controls." - This is one of the many reasons that I have used Real Studio for so long. Non-native controls just stick out like a sore thumb.
I CANNOT wait for April.
Is this using REALstudio Desktop or Web? Or will there be another "mobile" version of REALstudio?
@ infiniteline - It's not using either. iOS will be its own project type just like desktop, web and console are today.
Gotcha. I'm really looking forward to this, but I hope it's priced more affordably than Web. I don't do a lot of development and the current cost for Web has made it prohibitive for me to use REALstudio for those purposes.
Great! Can't wait. So far, we have only seen iPhone screenshots, wat about iPad?
Umm, the third screenshot above is an iPad screenshot :)
Well, no, it isn't. It is a screenshot of the Xcode iPhone simulator.
@ Unknown - an app runs in the simulator nearly identically to how it will run on actual hardware.
Aren't all screenshots from the simulator? Normal iPhone screenshots are not styled with an iPhone around them :D
Geoff: About multiple heights (not only iphone 5 vs. pre-5 but also managing call and internet sharing strips), I know it's handled dynamically in interface builder but I'm intrigued about how REAL plans to handle it. Will it be a bit like the current anchoring of windows and controls, where one defines what moves and what doesn't move when resizes happen and this would be essentially like a vertical resizing?
With Android now the most popular mobile o/s, do you plan to support Android as well as iOS?
@ Eduo Gutierrez - Automatic repositioning of controls will be similar to, though more powerful than, what we have today for windows.
@ Garry - Yes, we plan to eventually support Android. But it is a much more difficult platform to support on almost every imaginable level. First, requires that our compiler be capable of Java byte code output. Second, the entire framework must be written in Java (at least, that's what it looks like at the moment), third it's a testing nightmare due to the varied number of hardware specifications. Having said all of that, it's certainly a platform we plan to support.
No pressure on my end Geoff. iOS will be an amazing start! (That being said, when Android starts moving along, I'm sure we can develop a testing army to help the process)
Geoff, this is exciting! Keep up the good work.
Is the IOS-Version based on LLVM?
@ ap - Yes. Part of our reason for switching to LLVM is that it already has an ARM-backend.
When can I get my hands on this even if it is in beta?
@ cfitzsimmons - Contact us this summer.
@ Geoff Perlman - The wait will not be easy. I have some development that I might not be able to put off till then. Here's hoping for something soon
If RB will compile iOS apps it will be a "HUGE TWO HAND MONSTER SLAM DUNK".
Post a Comment