iOS 8 64bit only form Feb 2015

MobAmuse · November 2014

I'm sure many of you knew this was coming anyway, but I just uploaded a new iOS build today for one of my apps and got this warning below.

I was still allowed to upload of course as 32bit but was a little surprised to see it this early.

HubertRonald · November 2014

Yes, @MobAmuse

It was forewarned in the next link
https://developer.apple.com/news/?id=10202014a

But I don't know how we can update Gideros for this.

But as @jdbc I believe than I'll leave App Store, though I'm not totally sure :-?

ar2rsawseen · November 2014

Most probably it can be done, need to change building ios libs:
https://github.com/gideros/gideros/blob/master/scripts/buildioslibs.sh
with the -arch=arm64 flag

I have not tried but I assume it will have many errors mentioned here:
https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/ConvertingYourAppto64-Bit/ConvertingYourAppto64-Bit.html

And of course it needs to be retested on 64 bit hardware

First we will set up auto builds then will try to deal with 64 bits

jdbc · November 2014

A lot of efforts to publish to Apple Store:

- Buy a Mac
- Pay 80$ for a developer account
- Changing their policies to deal with their lastest OS
- Too long review and updating process
- Big learning curve to use their Xcode properly
- Most of the times low incomes

Now this.

If nothing changes I will leave Apple publishing next February.

EricCarr · November 2014

I use a MacMini (cheapest mac available, sometimes can find refurbished) for development/building.

Google Play is also requiring more things, like a physical mailing address soon.

Unfortunately it's just something we have to deal with as these app stores mature.

I'll take a stab at building in 64 bit to see the level of errors.

SimplesApps · November 2014

IMHO today I prefer the Apple Store.

-A Mac is a good investment (nothing to do with a PC & Windows 8…).

-Google don't filter the apps. Due this fact there are many apps but most of them have low quality.

-In GooglePlay you can't choose the meta data, Googles does for you. It's a black box, you only have to pray they put in the right way.

-The ranking in the Google Play most of the times don't have sense. You can find older apps in a higher position (compared to others with the same downloads and scores); maybe it's due to a hidden metadata... I think Google would have to change the algorithm in order to update the app ranking. Although sometimes Apple also have an incongruent ranking.

-Since last 30th September Google requires a physical mailing address if you have a paid app or in-app purchases. The address will be displayed to all users in the app store listing page. Bad for us as indie developers. Due to this fact many of us (me included) won't public paid apps in Google Play (having a PO box is a waste of money). Apple doesn't have this requirement. Nor does Microsoft. Even eBay doesn't require sellers to publicly list their address. All Google has to do is designate Google Play as the Merchant of Record (like Apple) and all of this physical address nonsense would go away.

-Google forces to use Google play services (and Google+ for the reviews).

-Due to the Android fragmentation sometimes the apps have problems.

-When you are building a project you have to fight Eclipse and the ADT framework issues.

-Most of the times low incomes. For me very low incomes.
Based on an AppAnnie report AppleStore is generating 60% more revenues than GooglePlay market, even as the latter has significantly higher download counts.
Read here:
http://www.ibtimes.co.uk/apple-app-store-vs-google-play-revenue-downloads-1470328

ar2rsawseen · November 2014

1) You can develop Android on both Mac or PC
2) Even if Apple filters something, there are still loads of crap on the appstore, only submission process is much more painful

3) ASO in Google Play is as easy as SEO, right description text is all it takes
4) Here I'd say both stores fail miserably, promoting apps that will earn them more money, and not more interesting or innovative represents
5) Most probably this one sucks the most about Google Play, but fortunately I don't experience it, as I don't have paid apps, but Google Play is only one store, and by my stats, not even the best one
6) True hating google for that
7) iOS requires more icon sizes, than Android probably has resolutions, but amount of resolutions for iOS also does not fall back much. Yes, Android has Kindle, Nokia X, and OUYA, but for all of them Gideros apps, seem to work out of the box
8) Dealing with xCode proved to be much more pain, than Android, at least for me

9) If you have paid apps, then most probably iOS will perform better, if Ads, then it all is based on the volume of users, which platform will provide more users, as in more Downloads. That is why I think some users report more revenue from IOS (paid and IAP) and others from Android (more downloads, generate more user volume, thus more revenue from Ads)
But I think that they both have the same problem, most of the revenue generated by iOS market goes to around 1% of top apps/developers and same for Google Play, most of the downloads go to around 1% of top apps/developers.

unlying · November 2014

Stop it, please) iOS and Android are great systems with their advantages:)
But topic is really important and we shouldn't start to argue about iOSvsAndroid here.

keszegh · November 2014

@unlying, so far it does not seem to be a flame-like argument, quite the opposite, i find it useful to see the pro's and con's for each platform. and i guess from the tone that it will remain a constructive conversation.

[although it is indeed not the perfect topic to discuss these.]

eezing · November 2014

Yep, developing for iOS requires a greater initial investment in both $$$ and time, but the reality is iOS users are more likely to purchase your app. Although Google Play downloads exceed the App Store by 25%, the App Store earns 50% more in revenue.

No doubt development for Apple is more strict, but if you plan to earn a living doing this stuff, it's pretty clear at this point that iOS users should be your primary target audience.

totebo · November 2014

Agree with @unlying. Let's stay on topic: How we continue developing iOS apps with Gideros after Apple have made 64 bit a requirement.

Is this a showstopper currently, or possible to do with the current Gideros build?

Mells · November 2014

At Unity they are talking about the same things.
I'm curious about the investment and resources needed to make it work.

ar2rsawseen · November 2014

@Mells they have problems because they are using C#, which does not use C++ underneath, have no idea how exactly are they doing it though, but it seems it should be very hard to convert the generated code to 64 bit native code. They now will introduce intermediary layer to compile/convert to c++, to run on ios devices

Lua uses c++ underneath (basically Lua runs on c++) so there, should not be such BIG problems, but yes, probably there will be some problems

ar2rsawseen · November 2014

Update on the matter

Discussed 64 bit issue with @atilim

So there are few problems.
All in all Gideros is 64 bit friendly, and it should not be a problem
But:
Problem 1:
1) precompiled lua is different for 32-bit and 64-bit
For those who use LuaJIT it does not matter, as they've disabled luac as described in installation file.
But if users are using simple export, it won't work, as lua is precompiled for 32 bits.

Possible solutions:
precompile both versions as 32-bit and 64-bit lua file versions, but well we all understand we don't want to make heavier apps, don't we.

So the best solution
Remove luac compilation step completely
But it would leave files more vulnerable (even with current encryption), so source code encryption should also be improved
I remember some of you guys wrote that you will try to improve it, so if you did feel free to commit to main repo, we will need it

Problem 2:
1) binaries are also different for 32-bit and 64-bit

The Gideros source itself should compile to 64-bit binaries without the problem, but
we don't feel that the time has come to move to 64 bit binaries completely and dropping off 32 bit devices, thus we will make fat-builds containing all binaries x86, 32bit and 64bit.

Conclusion
So technically it is possible and will be done, current priorities:
1) finish auto builds (@atilim is working very hard on it, as you may see from commits and hopefully soon will be done, now we are battling with builds being too long, travisci limits are 50 min

)
2) clean source code, remove paid license stuff, etc
3) add 64 bit to ios

But if anyone wants, you can try to make 64 bit compatible apps right now, theoretically.

1) first you need to disable luac:
Inside Gideros installation folder, right click on Gideros Studio and select Show Package Contents
Navigate to Contents/Tools and rename luac to luac2
Then reexport assets again to your xcode project
That will disable lua compilation, making your lua code 32 and 64 bit compatible

2) instead of using precompiled binaries as libgideros, you can copy Gideros source directly, I know copying hundreds of files does not seem wise, but you can do it, and xcode will build what it needs from sources automatically, same way it does with plugins (as for plugins you only provide sources, not binaries

)

jdbc · November 2014

For now it seems the best solution for 64 bits and iOS is to remove lua compilation from Gideros Studio or replace precompiled binaries with library sources in Xcode.

Mells · November 2014

@ar2rsawseen thanks for the thorough explanation.

dominikusdp · November 2014

@ar2sawseen great as usual

thanks for the explanation, will try that method (disable luac, using gideros source instead of the precompiled binaries) and discuss it here if there is something.

SinisterSoft · November 2014

@ar2sawseen - don't you mean fat arm binaries? The actual studio shouldn't need to be 64 bit as all you are doing is providing precompiled arm (currently 32bit) files + encoded lua script?

My vote is for standard Lua to go, with LuaJIT replacing it as default - makes things much simpler - but the encryption will have to be stepped up a notch - there should be notes in a (facebook) pm about how this could be done easily. The first thing that should be done is to extend the key at least sop that it's not just as simple as described in the pm.

Whilst adding 64-bit arm support for iOS - why not add it for Android too as it might be good for Android devices? (x86 x64 and arm x64)

@atilim Glad to see you are still around and helping overcome this problem.

ar2rsawseen · November 2014

@SinisterSoft gideros binary also contains i386 for simlators on ios, so it's not arm only
My first proposal was to remove lua and replace it with lua jit, but after talking to Atilim, he persuaded me to make luajit optional for some more time.

And yes great suggestion for android, after removing luac, that also should be possible

SinisterSoft · November 2014

Ahh - didn't know it would work with the simulator.

I know that Imagination Technologies are pushing MIPS and PowerVR Android devices in China - perhaps MIPS would also be a good (optional?) addition to Android fat binaries if using LuaJIT?

http://www.pcworld.com/article/2601040/first-mobile-device-with-mips-64bit-processor-coming-in-2016.html

http://blog.imgtec.com/mips-processors/new-mips-based-ingenic-newton-platform-targets-wearables-consumer-iot-devices

Maybe the export tool should have tickboxes for output formats?

btw: I can't understand the reasoning behind not moving to LuaJIT - any clues as to why?

ar2rsawseen · November 2014

I think Mips have other endianness so that might be a problem

And about output formats, yes that could be done for Android probably

About LuaJIT, I don't know, a gut feeling? For some reason Atilim wants to keep it optional for now

SinisterSoft · November 2014

The enhancements that luaJIT brings for introducing external libs is worth any gut feeling though. Isn't LuaJIT open source? - so there should be nothing to worry about.

MobAmuse · December 2014

How is the 64bit side of things going? ...or not of course. Getting ready to dump iOS in the new year by Feb 2015 if it's going to be too complicated to sort out. Not much cash in Free (with Ads) or Paid on iOS now, so don't want to waste too much dev time on it personally if it's going to be a pain to support 64bit onwards via Gideros easily.

Happy New Year!

MobAmuse · January 2015

iOS... 'First we will set up auto builds then will try to deal with 64 bits'

Is this still happening or not then?

SinisterSoft · January 2015

What needs to happen is the encryption needs to be beefed up -like in cocos2d - luaJIT need to be included in the builds though rather than plain Lua.

LuaJIT 2.1 dev branch is now working on ARM64.

I know it's now free, but all this needs to happen pretty sharpish before some users stop using Gideros and move to ther Lua based platforms - it needs more users, not less.

MobAmuse · January 2015

Whilst I don't make that much cash form iOS as compared to Droid these days, I would still like to retain the good customers that I have on iOS. On Feb 1st I will no longer be able to support them with new releases unless Gideros iOS is made compatible in latest Xcode. Currently I can build everything fine (32bit) but as some of my new projects will be released beyond Feb 1st I'm probably going to have to break the bad news to those customers that I can no longer support iOS - that will be a shame if so.

I can only therefore hope that gideros will be made compatible with iOS 64bit soon.

iPad Pro is coming so it needs doing I reckon.

If it was part of the new Gideros kickstarter I would prolly pay for this 'fix' to be done too as it's more important to have than say OSX target for example IMHO.

uzubari · January 2015

A new kickstarter campaign for primarily iOS 64bit compatibility could be a good idea. I hope someone planning for this. I think it is urgent than WP8 support.

SinisterSoft · January 2015

I thought @Atilim was on with this already though, the main stumbling block is Lua bytecode not being compatible - that's why the move to saving encrypted text (with stripped comments) is the move that other Lua based sdks are going - with LuaJIT it might not be a problem. I think LuaJIT also has it's own bytecode that maybe compatible between 32 and 64 bits with LuaJIT 2.1 - so this might be ideal?

yubaro · January 2015

I'm new to iOS. Hopefully they can fix it. :-S

petec · January 2015

I also need ios more than windows phone or desktop. Without it, then I'll reluctantly have to look elsewhere for a Lua based platform that supports 64 bit.

john26 · January 2015

As you may have seen from the other thread (http://giderosmobile.com/forum/discussion/5399/kickstarter-for-wp8-and-desktop-is-launched)

we have now decided to add 64-bit iOS support as a goal of the Kickstarter campaign. It would be silly to add new targets while losing an existing one and we want to respond to the opinions expressed here. It's actually not that difficult to add 64-bit support and we can do it within the £3000. And it makes sense to do it while adding the other targets.

Howdy, Stranger!

Categories

In this Discussion

Top Posters

iOS 8 64bit only form Feb 2015

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

iOS 8 64bit only form Feb 2015

Comments