Another +1 for this :)

@wradcliffe, @Tizzy, in case I gave the wrong impression, I'm not attempting to make Pythonista itself a cross-platform development environment.

My goal is to build a Python cross-platform app development tool, which uses Pythonista to provide cross-platform devs with better integration with iOS. Kivy doesn't seem to integrate well with iOS. For example, it does not look like I can embed a web browser on iOS using Kivy, and that's a necessary feature regardless of if I use it for UI or not, as I need to be able to load web content.

Speaking more generally on cross-platform GUI and WYSIWYG, I've actually contributed to wxPython and wxWidgets, and I can tell you, the workload required to maintain a cross-platform GUI toolkit AND get a solid WYSIWYG tool going is a ton of work, and you're constantly playing catch up as the native platforms add new APIs and functionality. While I wish the Kivy project luck, my past experience says that chances are I'm going to quickly run into roadblocks with support for various native things I want to do. Part of my goal with PyEverywhere is to allow cross-platform Python development in a way that avoids this sort of issue.

As for why HTML/JS/CSS, basically, since almost everyone uses a browser, browsers are the cross-platform GUI toolkits that get the most love by far, are highly performance optimized, and often have much of the device's native functionality exposed. Plus, there's lots of libraries and tools out there to help speed up development and add things like charts, games with sophisticated effects, etc. One of Python's big draws is the ability to pull in modules with lots of advanced functionality, and HTML/JS is the closest I've found to that on the UI side of things.

Anyway, sorry for any misunderstandings! I guess I conflated "developing cross-platform UIs in Pythonista" and "developing cross-platform UIs using Pythonista" in my head when responding. :)

Another +1 for this :)

@wradcliffe, @Tizzy, in case I gave the wrong impression, I'm not attempting to make Pythonista itself a cross-platform development environment.

My goal is to build a Python cross-platform app development tool, which uses Pythonista to provide cross-platform devs with better integration with iOS. Kivy doesn't seem to integrate well with iOS. For example, it does not look like I can embed a web browser on iOS using Kivy, and that's a necessary feature regardless of if I use it for UI or not, as I need to be able to load web content.

Speaking more generally on cross-platform GUI and WYSIWYG, I've actually contributed to wxPython and wxWidgets, and I can tell you, the workload required to maintain a cross-platform GUI toolkit AND get a solid WYSIWYG tool going is a ton of work, and you're constantly playing catch up as the native platforms add new APIs and functionality. While I wish the Kivy project luck, my past experience says that chances are I'm going to quickly run into roadblocks with support for various native things I want to do. Part of my goal with PyEverywhere is to allow cross-platform Python development in a way that avoids this sort of issue.

As for why HTML/JS/CSS, basically, since almost everyone uses a browser, browsers are the cross-platform GUI toolkits that get the most love by far, are highly performance optimized, and often have much of the device's native functionality exposed. Plus, there's lots of libraries and tools out there to help speed up development and add things like charts, games with sophisticated effects, etc. One of Python's big draws is the ability to pull in modules with lots of advanced functionality, and HTML/JS is the closest I've found to that on the UI side of things.

Anyway, sorry for any misunderstandings! I guess I conflated "developing cross-platform UIs in Pythonista" and "developing cross-platform UIs using Pythonista" in my head when responding. :)

@wradcliffe I'm actually working on a cross-platform framework I'm calling PyEverywhere for this. Instead of trying to wrap the native UIs for a bunch of platforms, it uses web UI instead, with a bridge layer that lets you call Python functions from JS and vice-versa. This way you can quickly build a cross-platform UI, and have your core app logic remain in Python. It uses Pythonista for iOS support, Kivy for Android support, and wxPython for Mac support. It could be easily extended to support Win as well, and it's on my TODO list, although I'm thinking of using cefpython directly for Windows as wxPython embeds IE by default there, which defaults to emulating IE 7. :(

It's still a work in progress, but you can learn more about it here:

http://pyeverywhere.org

Would love to collaborate with @omz if he had interest, particularly in the area of having some sort of cross-compilation system going for C++ extension modules. I think being able to run a couple commands to get a Python project that will run an app with a cross-platform web-based UI on iOS, Android, Win and Mac could be a game-changer for using Python as an application building tool.

If you are asking what the purpose of the Xcode template is when we already have the Pythonista app, the purpose of the Xcode template is to allow you to create standalone iOS apps using Python that don't require the end user to have Pythonista installed.

The Xcode template includes an iOS version of the Python runtime and an Objective-C function that runs the Python script you specify when the app starts. I'd say it's like the iOS equivalent of py2app or py2exe.

Does Pythonista have any way of passing down data from ObjC to Python, like say the launchOptions arguments that can be passed in on launch? Particularly I would like to pass the value of UIApplicationLaunchOptionsURLKey down into the script somehow.

Thanks, but I don't actually want to send the args to the Pythonista app, I want them to come to my own app, which is built using Pythonista. This is for "open in" functionality in my app.

As someone who's been programming for over 15 years, I've found that I agree with the Zen of Python here that usually explicit is better than implicit. Also, in my experience, when faced with an issue like this, the best overall results are gained by trying to help the programmer to understand exactly what the code is doing rather than hide those details away. I know it's common that beginner programmers want to avoid getting caught up in the gory details, but when they eventually do hit problems that knowledge really helps them find the cause and fix it.

Is running in the background important for most actions, or just a few special (but common) scenarios, like triggering a dialog? I've coded in a few different GUI toolkits, and usually event handlers are run on the main thread. Modal dialogs blocking the app is, in other toolkits, expected behavior, as often in those cases you need a response from the user before the app can continue. If you don't want that behavior there is usually a separate option for showing dialogs non-blocking, where you send in a dialog finished callback function or a delegate.