XCode 4 migration issues « cocos2d for iPhone

cocos2d for iPhone » Programming » iPhone SDK / UIKit / Objective-C / Xcode

XCode 4 migration issues

(32 posts) (6 voices)

Started 5 months ago by itlgames
Latest reply from Martin

Tags:

No tags yet.

12 Next »

itlgames
Moderator

Ok, perhaps I'm a bit tired since I have been working flat out for the last few days to meet a deadline, I am in the process to migrate (painfully) a few old projects to XCode 4 and so far so good, but I found this issue where few cocos classes properties are now readonly, I used to use the opacity and colour to assign directly, been doing this since, can't even remember. Now, since I try to compile with XCode 4, after I validated the project, I get the error:

"Assigning to property with 'readonly' attribute not allowed"

On color and opacity properties so far.

Before I did the project validation it was compiling ok. I did check all option on the validation, perhaps I should't have? Before I do try all possibilities there, anyone knows about this?

Yes I could change all direct assignments to the setter method, but before I change anything, I'm just wondering why this, or am I missing something?

Posted 5 months ago #
itlgames
Moderator

Forgot to say, I'm using cocos2d v1.1-beta, so latest version on 1.x branch

Posted 5 months ago #
itlgames
Moderator

Never mind, it seems it's a bad idea to import an old XCode 3 project and do the project validation, that will just break things. Either don't do the validation and leave it as it is, or just create a new project template and start over again.

Another inconvenient of importing an old XCode 3 project is that by default XCode won't create .ipa files, took me a while and lot of post suggestions to find something that works, it's the "Skip Install" building setting on the cocos2d library, needs to be set to "Yes".

Also took me a while to figure out how to use the different building settings I had on XCode 3 (debug, release,...) as it's now called "Scheme".

And another thing is that by default XCode 4 don't compile for armv6, so we need to manually add it under "Architectures" on the project building settings if we want to support old devices, we need to delete what it's there by default and just add "armv6 armv7"

Just sharing my frustrations in case it helps anyone else.

Posted 5 months ago #
zaaroth
Member

Havent you bumped into the oneway void warning? I got a lot of them on singletons and had to modify a bunch of method signatures to match what the new compiler asks for.

Posted 5 months ago #
clarus
Member

The armv6 thing is because Xcode "upgrades" your project to iOS 5.0 deployment, which can't happen on armv6. I think it's something that catches pretty much everyone. It's also a deployment setting that most people don't really want.

That "Skip Install" setting is a pain in the butt. I've hit that several times, with different errors making it sound like different issues.

Posted 5 months ago #
itlgames
Moderator

Ok I thought I was just grumpy, so I'm not alone! ;)

Posted 5 months ago #
unrealaz
Member

@itlgames Ipa files? Xcode 3 doesn't do that either. It creates the .app directory/file.
For XCode 4 indeed is no longer created in the build directory of the project but rather in some strange directory in the Developer folder.

To find that you have to go to the organizer and find your project and click on see project files or something (don't have xcode4 here).

Oh and one more thing about amrv6 & 7. If you don't set it to both and your application can be run on anything lower than IOs 5 you don't pass the submission validation from apple so it's wise to set it "armv6 armv7" (actually writing this in the architecture field without the quotes).

Posted 5 months ago #
itlgames
Moderator

@unrealaz of course XCode 3 does, I have been doing it for months, you Build and Archive, then go to Organizer, then Share to disk... done. XCode 4 is basically the same, but if you import an old XCode 3 project, by default, when you go to Organizer the package option (the one that generates the .iap) is disabled. It's something to do with static libraries, basically the cocos2d static library. Using the "Skip install" to "Yes" activates the .ipa solution.

If you also wonder how I use the.ipa file, I use this BetaBuilder app:

http://www.hanchorllc.com/2010/10/08/ios-beta-builder-1-0-1/

To generate distribution versions (I actually prefer this way rather than TestFlight, it's more elegant for client work)

Posted 5 months ago #
unrealaz
Member

Oh I just make a folder named "Game Name". In it I create a folder Payload, and in it I put the .app. Add the "Game Name" folder to archive and rename from zip to ipa and it works :).

http://www.funkyspacemonkey.com/howto-convert-iphone-apps-app-ipa

Posted 5 months ago #
itlgames
Moderator

Yes an .ipa is just a zip file, it's just nice to use the XCode functionality, cos every time you create an Archive, it saves all you need for you so no need to do manually, to for example symbolising a crash log of any previous versions you did.

Posted 5 months ago #
clarus
Member

I use BetaBuilder for distribution as well and recommend it. Some clients aren't excited about setting up new accounts for things like TestFlight, especially when many peeps need to install and test in & outside the company, and some of those users may not even be testers, like executive-types. BetaBuilder is a good solution for that. Send them a link, they open the page on the device and tap to install. Joy.

@itlgames, that "Skip install" issue with the compiled Cocos2d libraries bit me last week. What a waste of time. A useful error message would have helped. There's a lot of confusion about how to fix that on the 'net too. Doesn't help!

Posted 5 months ago #
itlgames
Moderator

Yeah, not very clear!

Wait, see this:

The error is back! I haven't done anything, and funny enough, the project compiles and runs ok!! wft!?!?!?

I didn't know about these semantic issues either...

EDIT: https://discussions.apple.com/thread/3091852?start=0&tstart=0

Posted 5 months ago #
itlgames
Moderator

Forgot to mention, the leaderBoardsMenu and achievementsMenu are CCMenu.

Posted 5 months ago #
varedis
Moderator

I just use the setOpacity methods instead it works fine but it may be a bit of a pain to go back and refactor everything.

Posted 5 months ago #
itlgames
Moderator

Yeah the thing is, is not a readonly property, so not sure why XCode 4 complains, it also doesn't complaint in all the .opacity references, only in some files. Weird.

Posted 5 months ago #
clarus
Member

CCLayer, CCMenu and CCMenuItem have readonly opacity properties.

Posted 5 months ago #
itlgames
Moderator

I think because the CCMenu conforms the CCRGBAProtocol protocol, you can access the setter, so that why you can access the variable directly (it is in fact using the setter). My question is why XCode 4 is complaining, probably gets confused, but maybe we will never know!... So moving on...

Posted 5 months ago #
Martin
Member

Interesting thread as I haven't dared to migrate to xcode 4 yet. Thanks for sharing!

@clarus:

I use BetaBuilder for distribution as well and recommend it. Some clients aren't excited about setting up new accounts for things like TestFlight, especially when many peeps need to install and test in & outside the company, and some of those users may not even be testers, like executive-types. BetaBuilder is a good solution for that. Send them a link, they open the page on the device and tap to install. Joy.

Don't you need to get the UDID of the clients device first, include it into the devices set as testing devices in your provisioning profile, redownload that profile and build, sign, upload your app again?! I always thought that this restriction can neither be circumvented by testflight nor betabuilder. I've been using beta builder, but only deployed to a device from which I included the UDID beforehand (the one time I tested it before I did include it, it didn't work).

Posted 5 months ago #
clarus
Member
Well, Xcode is complaining because CCMenu, CCMenuItem and CCLayer specify:
```
/** conforms to CCRGBAProtocol protocol */
@property (nonatomic,readonly) GLubyte opacity;
```
As to whether they should be readonly or not, the CCRGBAProtocol declares the opacity and setOpacity: methods as NOT optional, so you'd think the opacity property should be readwrite so the synthesized methods are added for both of those. Looks like a bug to me.
Posted 5 months ago #
itlgames
Moderator

@Martin yes, you still need the UDID of clients, but I can tell you this is way more elegant and professional to show clients the work in progress. As @clarus said, most clients don't want to create TestFlights accounts. I think TestFlight is great for beta testing with users though.

Posted 5 months ago #
clarus
Member

@Martin, yes, you always need UDIDs so if a new device is added, you need to update the provisioning profile in the next build. But, for example, I have one client who has 70 devices on their account because they're testing their valet software onsite at different hotels, casinos and theme parks. Once I get the UDIDs, then every new build works on all devices of course. So, at that point, it's just let them know a new build is out and have them tap to install from a web page they know to go to, which is no effort for them (especially compared to the old iTunes sync song and dance of old). I do have to update the devices/profiles when they send me a new UDID, but that doesn't happen that often anymore.

Also, there's another client I that's a large Health Foundation and they've had the CEO and large donors running the app. There again, they just wouldn't want to deal with TestFlight accounts for those users. I suppose you could have someone manage it all for them, but Beta Builder works just fine without that, and I've even had people compliment me about how easy it was for them to install a build. ha

Posted 5 months ago #
itlgames
Moderator

Well those issues I was saying are "semantic issues" or potential semantic problems in the code, something new in XCode 4, is not actually compiler errors. You can ignore them in fact, just bit annoying.

Posted 5 months ago #
clarus
Member
Hmmm. I'm not understanding. Why is it an Xcode problem if the properties you're trying to set are declared readonly, which they are? That seems like a definite compile issue to me. The protocol doesn't specify anything about the properties of a class. You could just as easily have:
```
@property(nonatomic, readwrite, getter=opacity,setter=setOpacity:) GLubyte thisIsMyOpacityPropertyWithAReallyBadName;
@synthesize thisIsMyOpacityPropertyWithAReallyBadName;
```
or even no property and just the opacity and setOpacity methods. All of those would conform to the CCRGBAProtocol for the opacity methods because the required protocol methods exist in the class. So, the protocol doesn't specify anything about the properties.

The only issue I see is that the opacity property shouldn't be declared readonly for those three classes.
Posted 5 months ago #
itlgames
Moderator

Well, this issues has raised now with XCode 4 only, not happening before, that why I initially created this post :(

As I say, is not a compiler error, it actually does compile ok and run on both simulator and device, they call it "semantic issues", something new in XCode 4.

Posted 5 months ago #
clarus
Member

lol, "symantic issues."

Posted 5 months ago #
Martin
Member

@clarus: Thanks! I just wanted to make sure I'm note missing some feature I didn't know of. I too think it's more elegant to use betabuilder. You could also customize the web page that betabuilder generates a little if you want to show a maximum level of corporate design towards your client (which can be a good thing I guess).

Posted 5 months ago #
clarus
Member

@Martin, exactly.

@itlgames, Hey I wanted to mention one other thing about Xcode4 that may or may not affect you. It affected me, but I know most people here are only developing on iOS.

There's no PowerPC support in Xcode 4 any more. That's an issue if you're doing Mac builds, because there are still plenty of PowerPC Macs in circulation and unless your app can't run without 10.6 or 10.7, it doesn't make any sense to exclude those customers. I'm finding most of my Mac clients still want fat binaries rather than Intel-only.

There are some explanations on the 'net on how to hack at Xcode 4 to add PowerPC support back, but I decided to hack at VMWare instead and make a virtual machine that can run Xcode 3 inside Snow Leopard on top of Lion. I like to keep the development environment pretty much as it ships so it can easily be recreated later. Anyway, with that approach, I'm able to build fat builds and even test them using Rosetta, all inside a 10.6 vm running on Lion. Rosetta doesn't run on Lion, so that's another bonus from the VMWare (or VirtualBox) approach.

Anyway, probably not relevant, but if you do Mac development it's a pretty big deal.

Posted 5 months ago #
itlgames
Moderator

Good to know, not affecting me fortunately, but not good. One thing I don't like at all from Apple is that lack of backwards compatibility... :'(

By the way, I am running Snow Leopard with both XCode 3 and XCode 4, and so far so good! So maybe you don't need to use a virtual box. Anyway I am sure my days are counted, at some point dear Apple will say, only Lion friends, and no more XCode 3...

Posted 5 months ago #
clarus
Member

After waiting a few months, I wanted to move to Lion (and absolutely didn't want to boot into different OS's depending on which code I'm working on) which is why I needed to virtualize it. Snow Leopard is still a solid development platform though. Plenty of good reasons to stick with it.

Posted 5 months ago #
Martin
Member

@itlgames: what do I have to do to keep my old xCode3 alive next to the new xCode4 when I install it? Is it enough just to rename the developers folder and make a normal install of xCode4 to the standard folder?
I'm still running snow leopard and until apple forces Lion onto me for some reason it'll most likely stay that way. Don't see a reason to switch yet.

Posted 5 months ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.