It looks like you're new here. If you want to get involved, click one of these buttons!
MobAmuse, bali001, SinisterSoft, uzubari
It was forewarned in the next link
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 :-?
with the -arch=arm64 flag
I have not tried but I assume it will have many errors mentioned here:
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
- 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
If nothing changes I will leave Apple publishing next February.
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.
-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.
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.
But topic is really important and we shouldn't start to argue about iOSvsAndroid here.
[although it is indeed not the perfect topic to discuss these.]
Fragmenter - animated loop machine and IKONOMIKON - the memory game
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.
Is this a showstopper currently, or possible to do with the current Gideros build?
I'm curious about the investment and resources needed to make it work.
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
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
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.
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
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.
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 )
Likes: hgvyas123, HubertRonald
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.
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
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?
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?
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
Happy New Year!
Is this still happening or not then?
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.
Likes: MobAmuse, seppsepp
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.
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.
Likes: MobAmuse, bali001, SinisterSoft, uzubari