On Sat, Jan 1, 2011 at 11:58 AM, Matt Sergeant <matt@...> wrote:
>
> BTW: It worried me a little bit that apple's app store requires you to use
> the Mac APIs for doing things like user data storage. Does that not allow me
> to use DBI and SQLite for DVDSpanner?
For what it's worth - I just pulled the trigger and signed up as a Mac
App Store developer. I'll let y'all know whether a CamelBones app can
make it through the approval process.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net

>> BTW: It worried me a little bit that apple's app store requires you to use
>> the Mac APIs for doing things like user data storage. Does that not allow me
>> to use DBI and SQLite for DVDSpanner?
>
> For what it's worth - I just pulled the trigger and signed up as a Mac
> App Store developer. I'll let y'all know whether a CamelBones app can
> make it through the approval process.
How did that turn out?
Seeing that Camelbones apps that link against the system Perl break
every time Apple updates the OS, I can see that they would not like that.
But they cannot really have a good reason against apps that bring their
own Perl, right? And since the app store only supports 10.6+ on Intel,
and we now have (or will soon have) the option to pick which core
modules to include, that could be a really slim build.
I wonder what they do with Java applications that include their own JVM.
Thilo

On Mon, Feb 14, 2011 at 11:52 PM, Thilo Planz <thiloplanz@...> wrote:
>>> BTW: It worried me a little bit that apple's app store requires you to use
>>> the Mac APIs for doing things like user data storage. Does that not allow me
>>> to use DBI and SQLite for DVDSpanner?
>>
>> For what it's worth - I just pulled the trigger and signed up as a Mac
>> App Store developer. I'll let y'all know whether a CamelBones app can
>> make it through the approval process.
>
> How did that turn out?
I haven't submitted any apps yet, CamelBones or not.
> But they cannot really have a good reason against apps that bring their
> own Perl, right?
I wouldn't think so, especially if it uses Apple's official
BridgeSupport files to manage its access to Cocoa APIs. That leaves
Apple firmly in control of what and when APIs are available for
bridged access. As I understand it, maintaining such control is at the
heart of Apple's policies with respect to "foreign" language tools on
iOS.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net