Can Codify develope apps for the iphone/itouch

i was wondering if i could try and create an app which would work on the iphone/itouch. or is codify only for the ipad?

Codify (soon to be renamed to Codea) is only for the iPad. It would be very difficult to edit code on an iPhone or iPod Touch, so we chose to focus exclusively on iPad.

Additionally, Apple is very strict about downloading code, so a standalone iPhone player may be hard to get accepted by them (how would you get code onto it?)

Regarding a standalone iPhone viewer. While it might get rejected this doesn’t mean we won’t try at some point in the future.

@Dylan: Again, iCloud? :slight_smile:

Wouldn’t iCloud only be useful if you have a Mac version of Codea and an iPad version? Or if you have two iPads? From what I understand iCloud can’t be used for arbitrary sharing like Dropbox or Github.

iCould could share files among devices, not just between iPad and Mac. In fact, first target of iCloud is file sharing among iOS devices. So, if there’s Codea Player on iPhone/iTouch, it could share the code with Codea on iPad. Just like Camera app on iPhone shares its photo roll with Photo app on iPad.

If you can cut/paste code on an IPad you can do it on the IPhone. I would say that some people would even be willing to code on an iPhone/ITouch as slow as that would be.

As far as distributions easy for end users, the code could be provided to twolivesleft. They could do a build that is only your app and post it on their account. There are several ways 2lives could collect a fee for the time and effort ( plus a bonus to keep the core product improving ).

Another way would be to create (or submit and get an e-mail) of a stand alone build that could be posted to the app store ( or itunes) separately.

Codea Player (no editing) on iPhone/iTouch/iPad should be a free app with no-ads as it will promote Codea Editor by itself. Codea Editor on iPhone/iTouch/iPad can be a paid app. IMO. :slight_smile:

Yes we wouldn’t sell a player only app, nor would we put ads in it.

Is it possible that the iPad version could have an “iPhone screen size” option for each project? So you could create iPhone games in iPad, ready for when the code is available to build and submit such projects to the app store.

How about we just make a Codea Viewer (which TLL is almost done with) that imports code from clipboard (because we can’t export code in Codea). In 1.3, there is a function supportedOrientation(). TLL should add IPHONE_PORTRAIT, and IPHONE_LANDSCAPE to that function. Just an idea. I would love it. And about exporting to Xcode, I’ve been asking TLL for Xcode export.

Or… we could simply use multiples of HEIGHT and WIDTH and all apps will just work no matter what the platform or orientation.

I’ve seen that suggestion many times. My reasoning not to @Bortels is because we have to manually test and do that for every device. Here it’s a simple telling Codea “Support this application on this platform you support” or “support all platforms”. And then it changes the WIDTH and HEIGHT constant to whatever the divide that’s viewing it’s screen size. Our programs should generally work in any screen size anyways, so you might as well do that. Just my idea.

@Matt46 - I would like it if you could please change the name from “codify” to “codea”. It’s the small things that bother me.

For every device??? No - you just have to use WIDTH and HEIGHT in your size calculations. You want something centered, use WIDTH/2, and it’ll work on every IOS device, ever, forever and on, without changing code.

The problem with “support all platforms” is that the aspect ratio changes, depending on portrait or landscale, and depending on if the console is there. If you did what you suggest, you’d still have to look at width and height to figure out the aspect ratio to make your graphics look normal.

A more recent discussion (where we went off topic and mentioned this)

I was just saying not to even bother with setting width and height. Just have Codea return the device’s screen size in WIDTH and HEIGHT. Forget the rest. Sorry for the confusiton.

Ahh. It didn’t click with me at first. What about os.getenv(“device”) to know what your running on and/or os.getenv(“HEIGHT”) etc.?

What everyone else said about using the standard HEIGHT etc. makes sense but sometimes for top level menu items, in app scrolling, and controls, you’d want to know what the limits of the device your on is.

On the same notion a os.setenv(“device”) = ITOUCH which only works within the Codea app not in a viewer could help.

Again there are other techniques to get around knowing your canvas or using HEIGHT to determine it but getting it directly may prove helpful

Sry for rambling, but another thought occurs. Not os.setenv but holding down on the Codea play arrow brings up an options for the small screens. Codea would set the os.getenv parms accordingly and display smaller. This smaller display could have the standard buttons (play, pause, etc.) outside of the display, have a border like the device it is pretending to be, and be superimposed on a stillshot of the code window (purely for wow factor/artistic effect, but having a working debugger would be a super wow … Ok calming down … Need to just be thankful for 1.3 coming soon)