Friday, February 15, 2013

iOS Update

It's time for another update on our progress towards iOS support. Lately we've been working on toolbars, navigation and the splitview, which is a control specific to iPad.

In the screenshot below, you can see the toolbar on the bottom. In this example, it's using icons. 



Toolbar with Icons
But they don't have to be icons. You can use regular buttons as well:


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:

Gavin said...

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.

Hal Gumbert said...

I CANNOT wait for April.

Chris Timm said...
This comment has been removed by the author.
infiniteline said...

Is this using REALstudio Desktop or Web? Or will there be another "mobile" version of REALstudio?

Geoff Perlman said...

@ infiniteline - It's not using either. iOS will be its own project type just like desktop, web and console are today.

infiniteline said...

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.

Unknown said...

Great! Can't wait. So far, we have only seen iPhone screenshots, wat about iPad?

Gavin said...

Umm, the third screenshot above is an iPad screenshot :)

Unknown said...

Well, no, it isn't. It is a screenshot of the Xcode iPhone simulator.

Geoff Perlman said...

@ Unknown - an app runs in the simulator nearly identically to how it will run on actual hardware.

Eduo Gutierrez said...

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?

Garry @ TriSys said...

With Android now the most popular mobile o/s, do you plan to support Android as well as iOS?

Geoff Perlman said...

@ Eduo Gutierrez - Automatic repositioning of controls will be similar to, though more powerful than, what we have today for windows.

Geoff Perlman said...

@ 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.

infiniteline said...

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)

Steveorevo said...

Geoff, this is exciting! Keep up the good work.

ap said...

Is the IOS-Version based on LLVM?

Geoff Perlman said...

@ ap - Yes. Part of our reason for switching to LLVM is that it already has an ARM-backend.

cfitzsimmons said...

When can I get my hands on this even if it is in beta?

Geoff Perlman said...

@ cfitzsimmons - Contact us this summer.

cfitzsimmons said...
This comment has been removed by the author.
cfitzsimmons said...

@ 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

Mark Strickland said...

If RB will compile iOS apps it will be a "HUGE TWO HAND MONSTER SLAM DUNK".