Apple Development: iOS, macOS, Swift, Dylan

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›27 »

Doc Block: Apr 15, 2003; Fun Shoe

Installed the 4.1 update from the Mac app store, and it totally hosed Xcode. Ugh... gonna delete then reinstall I guess.

edit: and either I typed my password wrong, or you have to be a registered Mac developer for Xcode 4.1 to download the OS X 10.7 docs :rolleyes:

Doc Block fucked around with this message at 09:00 on Jul 21, 2011

# ¿ Jul 21, 2011 08:06

Adbot: ADBOT LOVES YOU

# ¿ May 16, 2024 16:57

Doc Block: Apr 15, 2003; Fun Shoe

Can't you just copy the installer to a thumbdrive and then take it home? (should be in /Applications)

Is there anybody else here who's in the iOS dev program but not the Mac dev program that has Xcode 4.1? If so, could you please try to download the 10.7 docs (in the Documentation panel in Preferences) and let me know how it goes.

# ¿ Jul 21, 2011 20:18

Doc Block: Apr 15, 2003; Fun Shoe

Malloreon posted:

Is it feasible to make a game in HTML5, deploy it on a bunch of platforms, including iOS through PhoneGap?

Do you lose out on anything important going that route (IAP, performance, etc etc)?

We've got an idea for a game that we want to do a prototype for, but collectively our iOS experience is pretty light. HTML5, however, we can do much faster.

However, we want a native app on iOS so we can take advantage of the app store.

Depending on the type of game, performance can be a lot worse. Even for 2D games, native apps try to use the GPU for drawing, both for the performance benefits and the decrease in battery consumption.

Cocos2D is a pretty good native 2D game framework. I don't know how similar making games in HTML5 is to Flash, but people who know Flash say that Cocos2D's API is very Flash-like. It's very easy to learn.

As to suff like IAP and GameCenter, it depends on what PhoneGap supports. Might want to wait and see how the whole Lodsys thing plays out.

Doc Block fucked around with this message at 23:45 on Jul 26, 2011

# ¿ Jul 26, 2011 23:35

Doc Block: Apr 15, 2003; Fun Shoe

The app store uses Akamai for content delivery, and which server you end up downloading from is determined by DNS if I'm not mistaken.

People who use alternate DNS servers have reported having slow Mac app store downloads until they switched back to using their ISP's DNS server.

# ¿ Jul 30, 2011 15:39

Doc Block: Apr 15, 2003; Fun Shoe

lord funk posted:

Is the lag between touch event and drawing unavoidable?

This is a new OpenGL ES project, with a simple draw frame that draws a circle for each touch point. drawFrame is running of an NSTimer. I tried pushing the drawFrame method only when touches were updated - but there was a noticeable bottleneck when lots of touches updated quickly (the frames would get backed up, then catch up as fast as they could).

Is there a trick out there to avoid this? I'm drawing 2D only, simple geometric shapes.

What interval are you using for the NSTimer? Have you tried using DisplayLink instead?

# ¿ Jul 30, 2011 23:40

Doc Block: Apr 15, 2003; Fun Shoe

Try NSTimer with the interval set to something fast like 1/240. I've heard of people having issues with touches and DisplayLink.

# ¿ Jul 31, 2011 20:04

Doc Block: Apr 15, 2003; Fun Shoe

Maybe NSNumberFormatter?

# ¿ Aug 1, 2011 03:29

Doc Block: Apr 15, 2003; Fun Shoe

Maybe it's a symptom of another problem.

How much RAM does your dev system have? Xcode is a RAM hog.

Maybe try a fresh install of Xcode. Run the uninstall script, then delete /Developer and whatever else the various versions of Xcode have left behind.

# ¿ Aug 4, 2011 00:14

Doc Block: Apr 15, 2003; Fun Shoe

Why are you overriding release? 99.999% of the time there is no need to do that.

Don't worry about the retain count. Only concern yourself with retaining the things you need to keep around (unless their creator returns them retained) and releasing them when you're done.

If it helps, think of it in terms of ownership. If an object needs another object, and needs it to stay around for a while, then it should probably own that object. It indicates that it owns the other object by retaining it and when it no longer needs that object it relinquishes ownership by calling release on it.

It's ok for an object to have more than one "owner" if you have to, because it just means that both owners need to keep the shared object around.

Just don't call retain on objects whose creator calls retain on them for you, such as with [[Thing alloc] init]. Your object will still own it, and as such will still need to release it.

# ¿ Aug 4, 2011 20:40

Doc Block: Apr 15, 2003; Fun Shoe

The argument is that if some other thread tries to access the ivar after it's been released but before dealloc is finished, having it be nil'ed out will be "safe".

My opinion is that it's a waste of time. While trying to pass messages to nil might be "safe" in that it won't crash your program, it almost certainly will result in incorrect behavior.

Small White Dragon posted:

I've opened it that way, and it's somewhat indecipherable

Binary plists are supposed to be efficient for the archiver. It's not something that's meant to be opened up and edited by hand.

Doc Block fucked around with this message at 04:50 on Aug 8, 2011

# ¿ Aug 8, 2011 04:47

Doc Block: Apr 15, 2003; Fun Shoe

carry on then posted:

I'm just an iOS dev, and still learning Cocoa myself, but I think you should look up key-value observing (KVO) and bindings, which were meant to help alleviate these kind of problems.

Read Cocoa Programming For Mac OS X. While somewhat out of date (2008) it's still a good introduction (and a new edition is supposedly coming in October). The author tries to get the reader to do things The Cocoa Way, which is important if you're coming from another language.

Doc Block fucked around with this message at 06:39 on Aug 8, 2011

# ¿ Aug 8, 2011 06:34

Doc Block: Apr 15, 2003; Fun Shoe

For whatever reason you're getting nil.

Hell if I can see why, though.

One question: why are you doing

code:

NotSwingSetAppDelegate *delegate = self;
[preferencesWindow setDelegate:delegate];

instead of just

code:

[preferencesWindow setDelegate:self];

?

Also, you can store the delegate as the generic id type, which will allow it to take any object type as a delegate (not that it matters in this instance).
You can check at runtime to see if the delegate responds to the necessary selector by doing

code:

[delegate respondsToSelector:@selector(someSelector:)];

and probably cache the result instead of checking every single time. (do a custom setter that checks for any selectors you need). Probably also define a formal protocol.

# ¿ Aug 8, 2011 08:16

Doc Block: Apr 15, 2003; Fun Shoe

mc.schroeder posted:

But what if the other thread accesses your ivar after you've released it but *before* you set it to nil? Nilling out ivars will not help you with concurrency!

I hope I wasn't giving the impression that I thought it would.

Dangling pointers can be a problem, though.

# ¿ Aug 8, 2011 20:43

Doc Block: Apr 15, 2003; Fun Shoe

Yep, just set the deployment target to 4.2, which will cause anything introduced in 4.3 to be weakly-linked so that it will still run on 4.2.

Of course, if you use any 4.3-specific features you'll have to check and see if the OS supports them at run time.

# ¿ Aug 23, 2011 06:09

Doc Block: Apr 15, 2003; Fun Shoe

SeventySeven posted:

Also, are there any books of a similar learning curve dedicated to XCode 4?

The new version of the book is supposed to come out in October. Hopefully this also means Xcode 4.

# ¿ Aug 29, 2011 07:28

Doc Block: Apr 15, 2003; Fun Shoe

The Big Nerd Ranch dude's hate of dot-notation is pretty dumb IMHO. In the iOS version he just calls it "confusing" but in the OS X version he he says it's stupid and silly.

It comes across as just him not wanting to learn a new thing. Wonder what he'll think of ARC.

Luckily everything else in the book is pretty good.

Doc Block fucked around with this message at 21:10 on Aug 29, 2011

# ¿ Aug 29, 2011 21:08

Doc Block: Apr 15, 2003; Fun Shoe

Probably an LLC, though you should really really really talk to an accountant and an attorney, and go with whatever they recommend.

Doc Block fucked around with this message at 03:36 on Aug 30, 2011

# ¿ Aug 30, 2011 03:31

Doc Block: Apr 15, 2003; Fun Shoe

If you're trying to get around the rules by being sneaky or clever then yes, you are going to have problems.

# ¿ Sep 7, 2011 09:47

Doc Block: Apr 15, 2003; Fun Shoe

Funso Banjo posted:

I have absolutely no idea how they can tell this.

There's absolutely no way, that I can see from the SDK documentation, that you can tell if something has been illigitimately downloaded.

There are one or two threads over on iphonedevsdk about the issue, but their suggestions don't seem to work from feedback received.

You can do things like checking to see if the binary is encrypted, checking file modification times, exiting the app if it's a distribution build but a debugger is attached, etc.

Nothing a knowledgeable person with a hex editor couldn't get around, but as Ender.uNF said, most are just script kiddies.

# ¿ Sep 26, 2011 19:54

Doc Block: Apr 15, 2003; Fun Shoe

Your method expects to receive the CGPoint by value, and instead you are passing it by reference.

Also, it's on the stack so it goes away at the end of the function.

# ¿ Sep 27, 2011 20:17

Doc Block: Apr 15, 2003; Fun Shoe

yellowjournalism posted:

Awesome, I'll take a look at it. Honestly this is all me scrambling to see what's out there because I'm doing an interview today, and they're asking me what kind of stuff I would like to work with.

Yes, use Cocos2D for 2D games.

# ¿ Sep 29, 2011 02:10

Doc Block: Apr 15, 2003; Fun Shoe

lord funk posted:

Can someone explain this graphic result to me? I'm making a simple rect background with OpenGL, with different color corners to make a gradient. On my iPad 2, it looks like this:

In the simulator, AND the first generation iPad 1, it looks like this:

Why the difference?

Insufficient color precision would be my guess. Are you using a 16-bit or 32-bit framebuffer?

# ¿ Oct 1, 2011 22:53

Doc Block: Apr 15, 2003; Fun Shoe

From what I can remember it's where you make the OpenGL layer or EAGL layer or something. There's an option to have the actual framebuffer (not just a framebuffer object, which is what you're creating in that code snippet) be 16- or 32-bits.

Sorry I can't be more specific, I'm not at my dev machine right now.

edit: nm, you found it yourself.

Doc Block fucked around with this message at 00:10 on Oct 2, 2011

# ¿ Oct 1, 2011 23:57

Doc Block: Apr 15, 2003; Fun Shoe

chiyosdad posted:

Is it possible to do app development for iphone/ipad on something other than a mac computer?

Yes and no. Uploading your binary requires a Mac.

There are some engines/toolsets that will let you do development on Windows, such as UDK, but you still need a Mac to do the final upload.

Honestly, though, just get a Mac.

Any of the Macs in Apple's currently lineup are more than adequate for iOS development. So are most of the used Intel Macs, with the exception of the earliest ones that only had Core Solo or Core Duo procs, since those can't run Lion. (If you go the used Mac route, also be sure to avoid Macs with the Intel GMA 950 GPU, though the current Intel HD 3000 GPU is fine for iOS stuff)

My Mac (for both iOS dev and my main computer) is an early 2009 Mac Mini (with the old style case) with a 2.0GHZ Core 2 Duo and integrated nVidia 9400M graphics, and it runs circles around the iPhone 4 and iPad 2.

# ¿ Oct 10, 2011 07:33

Doc Block: Apr 15, 2003; Fun Shoe

Beginning iPhone Development (something like that) is pretty good.

Also, unless whatever book you're reading says not to worry and that it'll explain later, make sure you understand the material.

# ¿ Oct 10, 2011 14:18

Doc Block: Apr 15, 2003; Fun Shoe

pokeyman posted:

Where can I read more about this? (I believe you, I'm just curious.)

The UDK site specifically states that you'll need a Mac to upload your app.

I've always just used Apple's app uploader utility; I wasn't aware you could still upload small apps via the web interface.

# ¿ Oct 10, 2011 14:23

Doc Block: Apr 15, 2003; Fun Shoe

PT6A posted:

XCode is driving me nuts. I want to make a reduced-feature free version of my app, so this is what I've done:

1) Duplicated my original target.

2) In the new target, set the info.plist to use a different plist with a different logo and bundle ID.

3) Create two different versions of a header, one which #defines __FREE_VERSION__ and the other which doesn't, which are then put in different paths. The different paths are then added to the correct target as the user header search path.

What I expect will happen is that the second target will build with the new settings and behave the way I want. What is actually happening is that the second target produces the same thing as the first target, no matter which settings I attempt to change. I'm not a real expert at using XCode (which should be pretty clear), but I must be overlooking something incredibly simple. Why does my second target not want to use the settings from the Info.plist I've told it to use?

EDIT: Just tried it again after removing the duplicate target and all associated files... I still can't seem to get the two targets to behave differently. I can get them both to either build the free version, or the paid version, but I can separate them. Has anyone ever dealt with anything like this before?

EDIT 2: Unless someone has the magic bullet to solve this problem, I think I'm just going to switch the header files and plists manually. I've spent more time trying figure out how to do this the "right way" than it would take me to swap it out manually 20 times...

Instead of creating two versions of a header (which I suspect is where your problem is, for whatever reason), go to the build settings for the free version target, and in the preprocessor section define __FREE_VERSION__ or whatever.

# ¿ Oct 12, 2011 00:23

Doc Block: Apr 15, 2003; Fun Shoe

Interface Builder is a little different than in 3.x, which is what the book is written for.

It's not way huge different, though. IMO most of the differences are just from the transition to one window instead of several. The object library is still over there on the right, the inspector (or whatever it used to be called) is in the top right, etc.

Of course, I'm in the middle of a project and so haven't looked at Xcode 4.2, so maybe it is really different than Xcode 4.1. (Gonna transition my app over to 4.2 this weekend)

Doc Block fucked around with this message at 03:45 on Oct 22, 2011

# ¿ Oct 22, 2011 03:28

Doc Block: Apr 15, 2003; Fun Shoe

Cocos2D 2.0 is still alpha. Stick to 1.x for now (1.1 should go into Release Candidate status within a few weeks).

# ¿ Oct 25, 2011 02:25

Doc Block: Apr 15, 2003; Fun Shoe

McFunkerson posted:

I have a project set up in Xcode 4.1. The project builds and functions correctly on my development machine (MacBook Pro running Lion). But when I transfer my app to the machine we need to run it on, it bounces in the dock once and then nothing else.

The target machine is running OS X 10.4.11 server. It has 2 quad core 3 ghz intel xeon processors (Mac Pro 2,1). I'm not sure if it's the age of the OS, that it's server, or the processors that I'm not built for correctly.

In Xcode I'm building for both 32 bit and 64 bit architectures. My Base SDK is 10.6 (the lowest I can go). Valid Architectures are i386 x86_64. The compiler is Apple LLVM compiler 2.1 The Deployment target is set to 10.4.

Can anyone see something that is set up wrong?

If memory serves, in 10.4 GUI apps could only be 32-bit. In OS X 10.4, Cocoa and Carbon were 32-bit only. Only build for 32-bit and see what happens. Also, make your app log its startup progress to a file so you can see exactly where it's having trouble (if it's getting launched at all).

Make really really really sure you aren't trying to use something not present in 10.4.

It used to be that you were given the option to install the 10.4 SDK when you installed Xcode, but not anymore evidently.

# ¿ Oct 28, 2011 18:05

Doc Block: Apr 15, 2003; Fun Shoe

Sounds like you're going to have to go back to a non-Mac App Store version of Xcode. They've got the option during install to install the OS X 10.4 SDK if I'm not mistaken.

Supporting legacy systems like that is a major PITA. Especially if you're also trying to support more modern systems and features.

# ¿ Oct 28, 2011 18:49

Doc Block: Apr 15, 2003; Fun Shoe

edit: whoops

Doc Block fucked around with this message at 18:43 on Oct 29, 2011

# ¿ Oct 29, 2011 18:01

Doc Block: Apr 15, 2003; Fun Shoe

McFunkerson posted:

Thanks for the additional info. I didn't use blocks in my code, but I did use GCDAsyncSocket for networking so I expect that's where it's coming from.

Upgrading 10.4 isn't really an option right now. One of the main apps we use is still ppc only, when Lion killed Rosetta it killed our ability to upgrade. We'd have to track down a used copy of snow leopard server. It's actually put us in quite a bad position, because we also can't buy new computers and these are heavily used production servers.

This all has to do with automated page pagination for a printing press. We have 1 server that feeds 7 plants and if you ask me it's retarded that we've put ourselves in this position. In fact we make fun of our customers who still use quark 4 and then have their 12 year old computer die because they put themselves in the same position we're in now.

I might have to suggest running my app on a different box, it's not ideal, but it would work.

Yeah, 10.4 doesn't have Grand Central Dispatch.

It would be worth it to upgrade to 10.6, which has most of the niceties of 10.7 but still has Rosetta. You could use blocks, GCD, etc.

A better solution would be to find a replacement for that PPC app, though I'm sure you're well aware of this

Sulk posted:

Can someone explain why linking windows is so unbelievably loving difficult? I'm trying to create a main window for this map application the book wants me to make because I'd rather just learn how to make the window than use their hacked file. I keep getting errors saying that the nib was loaded but no view was set.

http://www.iphonedevsdk.com/forum/iphone-sdk-development/2180-loaded-nib-but-no-view-set-error.html

http://www.makebetterthings.com/iphone/where-is-mainwindow-xib-in-xcode-4-2/

I tried all of the solutions here. I linked the app delegate to the window as its delegate, set the window as the view controller/changed the class as it mentions, and I tried modifying various lines in the actual code. Nothing works. It's late and I'm just going to go to bed, but I'm really loving frustrated with how illogical this poo poo can be sometimes. Maybe MVC is just a really confusing thing that I'm simply not getting, or I'm (once again) doing something horribly stupid, but I'm following the instructions that people said helped resolve their issues and it's just not working.

I don't want to quit on this poo poo, but it's becoming absolutely infuriating at how some of Objective-C/the Framework's design works, and Xcode doesn't seem to do much to help you. It's not helping my case for not trying to work with C# instead. Perhaps I should just try their hack or simply skim over the rest of the map app chapter I'm on and move on until I follow the book's later guides to creating windows and the like. Who knows. (Sorry in advance for the rant. I'm just really frustrated.)

Follow the second tutorial you linked. Worked for me, does it work when you try? Remember, when you change the class names in Interface Builder you have to press enter after you type in the class name, or it won't take.

So when you change the class of File's Owner to UIApplication you have to press ENTER afterwards.

Here is a working test app, made by following your second link.

Doc Block fucked around with this message at 18:43 on Oct 29, 2011

# ¿ Oct 29, 2011 18:13

Doc Block: Apr 15, 2003; Fun Shoe

I didn't remove any code and it still worked.

As for self it's pretty much the equivalent of C++'s this. It points to the current instance of whatever class the object is. So if you make an object foo that has method bar, and in the code for foo you need to call bar, you'd do

code:

[self bar];
// and can access properties like
self.someProperty = 5;
// or like this if you're like the guy that wrote the BNR book and hate dot-notation
[self setSomeProperty:5];

# ¿ Oct 29, 2011 21:11

Doc Block: Apr 15, 2003; Fun Shoe

There's one that seemed decent enough after a quick glance, and it covers Cocos2D 1.0, the latest stable version. I'll look up the name once I'm back at my computer.

edit: the one I was talking about is the one you linked to. Granted, I've only glanced at it, but the book claims to cover Cocos2D 1.0, which as I said is the latest stable version, so I don't know how it could be out of date.

Doc Block fucked around with this message at 01:58 on Nov 4, 2011

# ¿ Nov 4, 2011 01:53

Doc Block: Apr 15, 2003; Fun Shoe

Sulk posted:

I understand that there's both OpenGL ES and Cocos2D, but is either of the two favored in the community? Based on my (admittedly very) brief reading, it seems like the former is the more official of the two, but perhaps I'm wrong in believing so.

OpenGL ES is pretty low level; with it you're literally feeding vertices to the GPU and managing the GPU's state. It's "official" in that it's part of the actual OS and the SDK. It doesn't have anything to do with anything beyond the GPU, though, and is just a graphics API.

Cocos2D is higher level, and has actions, timers, sprites, a particle system, tile maps, physics (via a 3rd party library), a menu system, and so on. Cocos2D's actual drawing code uses OpenGL ES. It's not "official" in the sense that it isn't written by Apple and isn't part of the SDK, but it's used by a lot of games and the developer works on it full time.

Doc Block fucked around with this message at 05:09 on Nov 5, 2011

# ¿ Nov 5, 2011 05:06

Doc Block: Apr 15, 2003; Fun Shoe

No. iOS 5 doesn't just randomly delete things, but it will delete some specific things.

You see, in addition to the folder that holds the actual app (binary, icons, etc.), each iOS app gets a few other folders: Documents, Cache, and tmp

An app's Documents folder is for data the app needs to keep around that can't be automatically recreated or redownloaded (game saves, etc.), and so Documents gets backed up during sync, but Cache and tmp do not. tmp is for any file the app only needs temporarily, such as lock files or whatever. Cache is for anything that is useful to have locally but that can be recreated/redownloaded if necessary, such as a cache of downloaded image thumbnails for a table view.

With iCloud backups, Apple understandably does not want developers lazily storing anything and everything in the app's Documents folder, so AFAIK they've been trying to make sure devs are using tmp and Cache where appropriate.

For 90% of apps this is fine, but some apps and use cases fall into a gray area. For instance, an app like Read it Later that caches web articles for offline viewing later. The appropriate place to put them is Cache, since they don't need to be backed up and can be redownloaded, but on the other hand the whole point of the app is to cache web pages for offline viewing later.

Imagine needing to take a long plane ride. Thinking ahead, you fill up your iPhone with, among other things, web articles using Read it Later (which puts them in it's Cache folder). Then you get on the plane and see that iOS 5 has helpfully decided to do you a favor and free up some space by clearing out Cache folders.

And since right then Read It Later's Cache folder is the biggest, that's the Cache folder that gets cleaned first.

Most of the time, clearing out tmp and Cache when storage space is low is a good idea; Apple just didn't think of all the implications.

edit: hopefully this makes sense, it's what I get for doing this at nearly 2 AM.

Doc Block fucked around with this message at 09:02 on Nov 5, 2011

# ¿ Nov 5, 2011 08:22

Doc Block: Apr 15, 2003; Fun Shoe

Maybe try Lua and strip out any of the additional libraries and whatnot that aren't math related.

# ¿ Nov 6, 2011 01:00

Doc Block: Apr 15, 2003; Fun Shoe

PT6A posted:

Okay, so I want to make a free version of one or two of my apps to get people to download it and try it, because my sales numbers have gone up for the one app I made a free version of. The problem is that Apple rejected this app because, despite the huge number of Lite/Free versions of things on the app store, it's forbidden.

What I want to do is transition the current (paid) version to a $0 price, and allow people to unlock the full feature set through an In-App purchase worth the original price of the app. I don't want to make people pay twice, because that's obviously not fair. Will Apple moan if I figure out a way to have the features unlocked for users who have already paid for the app once? Are there any best practices I should follow for this situation?

Maybe you could push out one more update before you go freemium, and all that one update does is put a file named paidfor.dat in the app's Documents folder (or adds it to the app's settings, or whatever).

Then when you do your freemium update you change it so it instead looks for paidfor.dat and if it's there then you know it's an existing user.

Or something along those lines. Doing it exactly like this will be trivially easy for pirates to circumvent, but they're gonna try to get at the paid parts of your app any way you do it.

# ¿ Nov 20, 2011 21:45

Adbot: ADBOT LOVES YOU

# ¿ May 16, 2024 16:57

Doc Block: Apr 15, 2003; Fun Shoe

No, I don't think so. For obvious reasons, in-app purchases require user approval. In fact, if memory serves, once the app tries to initiate an in-app purchase iOS itself takes over and asks the user if this is what they actually want to do.

edit: and even if the API allowed it, it's doubtful that Apple would be OK with a secret in-app purchase even if it was free. Apple has to approve your in-app purchase items too.

# ¿ Nov 21, 2011 00:10

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Apple Development: iOS, macOS, Swift, Dylan

«‹›27 »