|
Let's talk about writing any code for iOS, macOS, tvOS, and watchOS! And let’s talk about writing Swift for anything! What this thread is about Anything to do with coding for anything Apple has ever made. Apple II through iPad Pro. HyperCard through Swift. Hiring developers (bring money). Any App Store. Safari. Books. AppleScript. There are people in this thread who have been doing Apple-y development for literally decades, people who are currently working at Apple developing cool stuff, and people who are just getting started. Everyone’s welcome! Get started If you’re making something for any Apple platform, your first step is probably to install Xcode on your Mac. It’s free and you can find it in the Mac App Store. You’ll use Xcode to develop iOS, Mac, Apple TV, and Apple Watch apps. If you don’t have a Mac, you’ll need to get one; it won’t necessarily need to be brand new, but a ten-year-old MacBook Air isn’t gonna lead to funtimes either. Ask the thread if you’d like recommendations to fit your budget! If you want to try out Swift on your iPad, get the Swift Playgrounds app from the App Store. It’s free and provides a full-blown Swift compiler and a handy environment for writing Swift, plus numerous tutorials and other activities. You can also try Swift on your Linux machine? That’s a thing! Installing your iOS/TV/watch apps to your own iOS/TV/watch devices is free, but distributing to others requires an annual Apple Developer membership. Running your Mac apps and/or sending them to others is free; distributing via the Mac App Store requires an annual Apple Developer membership. There are many tutorials online about getting into iOS dev. There are books. There are university courses. Feel free to ask in the thread if you’d like suggestions. Getting into Mac dev? There’s some still-good resources in the “archive” Apple Developer site. Don’t be scared of the warnings about being out-of-date; the Mac doesn’t change that much and it doesn’t change that often. Especially the more introductory or conceptual bits will serve you well for a brand-new app you’re starting today; you can always read the release notes to get up to speed once you get your footing. Handy development bits Your package management options are Carthage, CocoaPods, Swift Package Manager (Linux and Mac only, as I write this in January 2019), or manually copying files and dragging them into your Xcode project. That said, Apple platforms ship with a rich collection of mature frameworks with a ton of functionality, so you may find that you need few or no external libraries to build even the most complex app. Whereas in JavaScript-land your first instinct may be to search npm for a library, in Apple-land your first search query should go to the platform documentation. Worth watching Apple Developer videos, including sessions from Apple’s annual developer conference called WWDC (don't forget prior years!). pokeyman fucked around with this message at 02:36 on Jan 9, 2019 |
#
¿
Mar 27, 2011 19:08
|
|
|
|
| # ¿ Apr 29, 2024 08:50 |
|
|
Relevant SA Threads Threads with nearby topics:
Goon projects doing Apple-y development: Moribund technically-adjacent threads: This thread's predecessors: pokeyman fucked around with this message at 02:11 on Jan 9, 2019 |
|
#
¿
Mar 27, 2011 19:09
|
|
|
Collected thread wisdom Provisioning profiles explained! You've set an exception breakpoint but want the message too? Set the breakpoint action to po $eax. cite pokeyman fucked around with this message at 13:46 on Mar 15, 2013 |
|
#
¿
Mar 27, 2011 19:09
|
|
|
multigl posted:learn how to use blocks and impress your friends and have women fall over themselves getting to you That's not even hyperbole. Thanks! Anode posted:For the related threads And thanks to you!
|
|
#
¿
Mar 28, 2011 16:30
|
|
|
OHIO posted:You sound like you care about details and understanding the fine points, which is awesome, so if you want more info read up on both of those methods in the documentation. For example, what I just did before I read OHIO's response: switch to Xcode, hit command-option-shift-/ and typed 'applicationdidfinish', hit the first result, and read: "This method is used in earlier versions of iOS to initialize the application and prepare it to run. In iOS 3.0 and later, you should use the application:didFinishLaunchingWithOptions: instead." (And 'application:didFinishLaunchingWithOptions:' was a link.)
|
|
#
¿
Mar 30, 2011 19:13
|
|
|
Fists Up posted:So I need to know if the books reccommended in the op like [iPhone Programming: The Big Nerd Ranch Guide] will suit me? I haven't looked at the book beyond the pages Amazon makes available, but based on that and a couple reviews I've seen, this book assumes no prior knowledge so I think you'll be ok. The annoying part is it doesn't cover Xcode 4 or iOS 4 (the next edition does but it's in pre-order right now), so you'll want to brush up on those separately if you go ahead with this book. I taught myself without books (from the docs and searching elsewhere), so maybe someone who actually used books could weigh in.
|
|
#
¿
Apr 1, 2011 04:34
|
|
|
Ixian posted:Anyone have any ideas on directions to look in? currentTime works great on my iPad running iOS 4.3, even switching to/from fullscreen. edit: I used this little page to test it out. View source to see what I did. pokeyman fucked around with this message at 19:28 on Apr 1, 2011 |
|
#
¿
Apr 1, 2011 19:20
|
|
|
NOG posted:
Try: code:pokeyman fucked around with this message at 20:27 on Apr 7, 2011 |
|
#
¿
Apr 6, 2011 23:55
|
|
|
Public service announcement: don't call -[NSNotificationCenter removeObserver] outside of dealloc. tldr: you unregister your superclass too, which can break things. Instead use the more specific -[NSNotificationCenter removeObserver:name:object:]. I bring this up partly to ask a question: what if your superclass also registered for the same notification from the same object, then you deregister it specifically? Are we just hoping that, like the lack of namespaces, collisions just don't happen?
|
|
#
¿
Apr 7, 2011 20:38
|
|
|
UraniumAnchor posted:Yeah the guy I was talking to said he was under the impression it was too slow for game logic on an iOS device, but if Angry Birds uses it extensively then maybe he misheard. Or maybe the person he talked to was just a bad programmer. Tap Tap Revenge is widely thought to use it too. It's almost certainly not going to be your performance bottleneck. Lua's pretty fast. quote:So how would this work with DLC addons that include scripts? I assume I could get the addon approved by Apple and this wouldn't be an issue. That is a fantastic question. If you can't include the scripts in the DLC, you could always package all scripts in the app bundle and just unlock them with an in-app purchase.
|
|
#
¿
Apr 7, 2011 20:45
|
|
|
monkey posted:I need a scrabble dictionary in memory to do some very fast spellchecking, hopefully checking about 100 words vs 250,000+ words in a single frame. First step is to use an NSSet, not an NSArray, because you don't care about order. But when you run into the same problem, check out tries, their memory-saving counterpart radix trees, and their goofy cousin dawgs. There's also plenty more where those come from, so poke around. The idea is to use a data structure whose lookups take time proportional to the length of the word you're checking, as opposed to time proportional to the number of words in your dictionary. If filling this data structure takes too long on the device, you can do it beforehand and dump it to a file, to be loaded on the device when needed. Comedy option: let ragel do the work for you.
|
|
#
¿
Apr 17, 2011 12:25
|
|
|
monkey posted:Are you saying NSSet containsObject is faster than a binary search in an ordered array? I'm not familiar with NSSet, but that seems pretty amazing. I don't know if you're familiar with big-O notation, but if you are, binary search is O(log n) with n the number of words while a hash table (NSSet) is O(1) amortized. If you're unfamiliar with big-O notation, learn it, it's useful, but the translated version of the above is binary search takes longer when you have more words, while a hash table doesn't. edit: Small White Dragon posted:Absolutely you can. http://www.youtube.com/watch?v=q73MjnazIfg#t=0m23s pokeyman fucked around with this message at 22:23 on Apr 17, 2011 |
|
#
¿
Apr 17, 2011 22:20
|
|
|
monkey posted:Familiar enough to realise it's not O(exp n) so there's not much speed difference between 2,000 and 200,000 words. Would NSSet be practical to store nothing but long ints like in the stackoverflow link Bob Morales posted? I mean practical in terms of the memory footprint and any memory thrashing it may have, compared to just 1 static long int per word? Foundation collections are a pain to use with ints because you have to keep boxing/unboxing them. I'd probably just find/write some C hash table (or use CFSet if you're really partial to Apple libraries).
|
|
#
¿
Apr 18, 2011 00:48
|
|
|
Bob Morales posted:Let's say you're making a falling blocks game, using UIKit. For a 10 square by 10 square game field, would you make an array of UIImageViews, or would you just make an array of a 'block' struct/objects? The difference here is in the first case you're combining a model and a view, whereas in the second you're separating the two. I'd recommend the second; I find this separation easier to do from the start than later on, and you inevitably need to do it. quote:If I used the second way, would I just use a method like drawAtPoint to draw the bitmap for the block for each cell in the gameGrid? Let's say I'd have < 20 images total, some for different colors of blocks and then maybe 'jewels' or another piece of each color. You could use a bunch of UIImageViews, or just use UIImage's -drawAtPoint: or -drawInRect:. Maybe wrap this up in a UIView subclass, so you can just tell your custom view -drawBlock:atX:y: in your view controller.
|
|
#
¿
Apr 18, 2011 03:17
|
|
|
WildFoxMedia posted:Any tips/suggestions, etc? I'm not sure I entirely understand your question, so apologies if this is useless. If you're targeting iOS 4.0+, have your API library take blocks as completion handlers. code:
|
|
#
¿
Apr 18, 2011 22:48
|
|
|
Ender.uNF posted:You can also just take a list of blocks. Or maintain one. [thinger onSuccess:^(id result) { ... }] adds the block to the array of success handlers, all of which are called on the success event. Like an EventEmitter. That'd be handy to have for Foundation actually... Ender.uNF posted:Just don't fall into the trap of thinking that because you didn't have to write new methods or re compile that you are doing a good thing. I've known too many people that think having an ultra-flexible interface or doing stuff in SQL stored procs are great because hey - changes without a new build! Sounds like a case of You Ain't Gonna Need It. Don't code anything you're not using right now. Don't extract code into its own framework/project unless you're actually using it from more than one place. Don't add features you aren't using or testing constantly.
|
|
#
¿
Apr 18, 2011 23:40
|
|
|
Mikey-San posted:Objective-C Runtime Programming Guide Sniped for the OP. Thanks!
|
|
#
¿
Apr 22, 2011 09:32
|
|
|
KidDynamite posted:Just a quick question for you guys I should be able to completely code compile and run programs on a hackintosh? I want to start coding asap but don't have the funds for a MBP yet. As far as I know, yes. But please don't yell at me if that's wrong.
|
|
#
¿
Apr 23, 2011 09:21
|
|
|
Sir Davey posted:Is this the place to ask about AppStore rejection? I have nothing useful to tell you about anything in your post, but for what it's worth I'm perfectly happy with App Store chat here, so by all means.
|
|
#
¿
Apr 23, 2011 10:46
|
|
|
lord funk posted:This was my original reason to make the switch to NSSet, but after a bit of research it's probably going to be just as hard to keep track of where my objects are than my silly index following system. I think I have a better idea of when to use which now, but for this program it's not worth the redesign. This might have nothing to do with anything but NSIndexSet makes keeping track of indexes considerably easier (and you can even ask an array for objectsAtIndexes:).
|
|
#
¿
Apr 27, 2011 19:47
|
|
|
^^^^^ Well that was impressive timing. wellwhoopdedooo posted:tab bar stuff Can you post your project, or an example of it? I'm having a hard time following you here. quote:three memory leaks, one for each view You're also leaking the array, so four.
|
|
#
¿
Apr 30, 2011 09:00
|
|
|
Lumpy posted:
Just to be clear, you don't receive the ...willHide... message at all? Or does it not come with a bar button item? Assuming the former, are you sure that you have the correct delegate assigned before you change the view controllers? You may be able to get the split view controller to re-send the message by sending it didRotateFromInterfaceOrientation:. But I'd consider that a workaround for a bug which you should file if you can't find any other way to get a new bar button item after changing the master view controller.
|
|
#
¿
Apr 30, 2011 09:09
|
|
|
I helped write an app that's been in review for a couple of weeks. The only communication from Apple was the boilerplate "this is taking a bit longer" note that was received a couple of days after submission. Since then, nothing. Has anyone else in this position managed to email, phone, or otherwise usefully make contact with someone to at least see what's up? Obviously I don't think there are any infringements in the app but equally obviously that view isn't yet shared by those who matter.
|
|
#
¿
Apr 30, 2011 19:00
|
|
|
wellwhoopdedooo posted:1: Is there a way to hide a method that a superclass implements in a subclass? I'm guessing there's not, but if that's the case, how do you handle subclasses requiring additional information before they're in a valid state? e.g. as in other languages where you have to manually implement every constructor in subclasses. Or is even requiring additional information not a good idea in Obj-C? Do subclasses not mean quite the same thing as in C++/C#/similar? How deep does this rabbit-hole go? I'm not entirely sure what "hiding a superclass's method" has to do with "subclasses requiring additional information". I'm kind of curious: can you give an example of a scenario that would motivate you to subclass but not support all of the superclass's methods? Anyway, if you find a use for it, you can implement the methods you want to "hide" in your subclass by sending doesNotRecognizeSelector:. As for overriding every constructor, Foundation (not Objective-C itself) has the concept of a "designated initializer". Other initializers eventually call the designated one, and subclasses then only need to call this designated initializer to get the superclass ready to go. (If your subclass changes the designated initializer, you should implement the superclass's designated initializer and have it call your subclass's new one.) quote:2: I see that I can sort of get pure virtual functions with protocols, but is there a way to make a superclass force its subclasses to implement a protocol? Or is there a better way to go about this? Am I thinking too C++ish again? Have the superclass adopt the protocol, and all subclasses are similarly bound. If you want to test an arbitrary object's conformance with an arbitrary protocol, send it conformsToProtocol:.
|
|
#
¿
May 1, 2011 06:24
|
|
|
Yakattak posted:I find developer support extremely accommodating. Cool, and thanks for the other responses too. I'll chill out for a bit.
|
|
#
¿
May 1, 2011 06:24
|
|
|
wellwhoopdedooo posted:I imagine the answer will be that in Obj-C, the usual way to do things is that if somebody instantiated LoggingFileWriter with the single argument constructor you'd delay the error until they called [instance write:@"something"] without setting .logger, but I really like trying to make things as close to impossible to use wrong as I can, so I'm asking even though I'm fairly sure I already know the answer. I'm assuming that, in your example, LoggingFileWriter subclasses FileWriter, but you don't want anyone to be able to instantiate a LoggingFileWriter without passing in a logger, right? That clarifies what you meant. Thanks. What would more likely happen without setting .logger is that .logger would be set to nil when the instance was initialized, so whatever message you wanted to send to the logger would evaporate into the ether and return nil. Presumably at this point the person using your code will wonder why the log file never gets written, and will figure it out. I think you're approaching Objective-C with too much of a C++ mindset. Which is perfectly ok! Just be aware of it. C++ has much more of a "make errors impossible" kind of mindset, while Objective-C seems to go more towards "handle errors gracefully". (I think the dynamism of Objective-C makes many errors harder to find before they happen, and that's part of why there's more faith put on the person using the code.) There's a couple of ways that I deal with it: I turn on some warnings, and I assume more competence on the part of the user of my code.
|
|
#
¿
May 1, 2011 07:49
|
|
|
Lumpy posted:I'm working on a app with another developer, using hg as our source control. The one problem we're having is when we add files or groups. Is it possible to have files and groups somebody else added show up in the project? Add the .xcodeproj to the repo, then add the user-specific stuff to your hgignore (that's a gitignore, but I think the syntax is close if not identical).
|
|
#
¿
May 3, 2011 01:09
|
|
|
Ender.uNF posted:Also a protip: when you create a view for a universal app (or an iPad app) and want the view to have a smaller size, delete the default "View" from the XIB (Xcode won't let you change the view size). Then drag a new View object onto the canvas and hook it up to the file's owner "view" outlet. Now you can change its size, yay! Holy hell that got annoying, thanks!
|
|
#
¿
May 3, 2011 01:45
|
|
|
NOG posted:That said, I'm trying to learn more about key-value coding. I've been wanting to accomplish a specific idea I have, but I don't know if it's the best approach or even possible. I'm sure you've had a look at the Key-Value Coding Programming Guide. Specifically, I mean the part where it discusses resolving key paths to values. If a method with the same name as the key is implemented, it gets called and its return value is the value for the key path. Otherwise, if an instance variable with the same name exists, its value is returned. So if you want [layer valueForKey:@"collidableCoordinate"] to give you tile coordinates, implement -collidableCoordinate on the class of layer. If it's not a class you control, implement it in a category (with a prefix, like -nog_collidableCoordinate). Also keep in mind that the return value from -valueForKey: will be boxed (i.e. an NSValue or subclass as opposed to an int/float/struct), so you'll likely need to unbox it first.
|
|
#
¿
May 4, 2011 20:59
|
|
|
Ender.uNF posted:On an unrelated note does anyone around here speak German (or any non-English languages)? I want to translate my app but I don't have the resources to haul off and do it on my own. I need a native speaker who is willing to help perhaps in exchange for something you can only get in the US, a gift basket, or a small fee. Hit up SA-Mart or the thread for the given language in the academics (?) subforum.
|
|
#
¿
May 6, 2011 03:20
|
|
|
Lumpy posted:Do I make a single UIProgressBar and hang onto it in the class, and add it to the cell view of the appropriate cell (but then what happens if / when I reuse that cell?) Do I give every cell a progress bar, and only show it in the appropriate cell? If so, how do I handle it's delegate as it pops in and out of existence on scroll? Sounds easier to me to have give a progress indicator to each cell, then have some way to toggle the cell's state between 'loading' and 'loaded'. Like in iTunes.app when you download multiple files, they all have their own progress bar that sits there doing nothing until it's that file's turn to download.
|
|
#
¿
May 6, 2011 20:51
|
|
|
Small White Dragon posted:Can I have my UIViewController be transparent to the one behind it? UIViewController does not itself appear on the screen, so I assume you mean its view. Feel free to set its view's opacity, but I wouldn't expect the stock container view controllers to work like you seem to want. For example, if you push a semitransparent view controller on to a navigation controller, don't assume you'll see both view controllers' views. Another thing to think about is passing touch events, orientation changes, and all that to view controllers that are visible behind your semitransparent one. I'm curious, what's your intended use case here? I feel like there's a better way to solve your problem.
|
|
#
¿
May 6, 2011 20:55
|
|
|
Ender.uNF posted:I thought it was 3.0 that introduced the "modern" runtime (non-fragile base classes and the ability to add ivars dynamically) and was the last ABI change but I could be wrong. I don't think it was ever introduced, iPhoneOS started on the modern runtime. If there was a transition it wasn't for 3.0, the only relevant API diffs are for a version constant and NS_NONATOMIC_IPHONEONLY.
|
|
#
¿
May 11, 2011 08:21
|
|
|
mmm11105 posted:protection if the internet goes out. Check this out. And check this out. Doesn't really help on the "native experience" front though.
|
|
#
¿
May 16, 2011 04:08
|
|
|
Ender.uNF posted:Viola! I am 100% not being a typo-correcting asshat, I just love this one because the concept of someone exclaiming "viola" is very funny.
|
|
#
¿
May 18, 2011 08:00
|
|
|
wellwhoopdedooo posted:[tell] me about Core Data. For me, Core Data answers the question "what can I use to persist my model objects, assuming I don't give a poo poo at all about how it's done?" In theory, there's basically zero friction when using Core Data. Need to fetch a collection of related objects? Just use them and Core Data will fetch them on demand. Need to save everything? Just send -save. Need a new scratchpad to make some objects and relationships? Fire up a new context and save it (or ditch it) when you're done. Core Data is fast as hell, there's almost nothing you can do faster if you do it manually. Oh, and mogenerator is fantastic at writing cruft-removing code for you. In practice, I find Core Data to be quite painful. Maybe it's because I get mad at it and swear off using it for months, thereby forgetting everything about it in the intervening period. But I find its promise of free undo management consistently broken (the actions sent to the undo manager were whacked). Handling validation errors at save time really sucks, especially on the save just before the app quits. And I typically have to write some code over top of Core Data to do away with some of its verbosity (check the docs for, say, fetching all the objects of one kind). And NSFetchedResultsController sucks. Overall, if you like accessing databases in C, you might find Core Data just gets in your way. On the other hand, if you're of the opinion that less code means less time wasted debugging and supporting, Core Data can replace huge chunks of your code. Just don't believe all the hype around Core Data! You still need to write code, undo isn't free, etc.
|
|
#
¿
May 23, 2011 21:05
|
|
|
fankey posted:I'd rather not have a bunch of dummy accessor functions that return garbage since I'm not storing the state - it gets passed on to another layer. A setter is not what you want if you're literally doing nothing but passing along the message. Just make it a method. Maybe you could post the actual problem you're trying to solve and we can help organize it for you? (Note: code is better than a description.)
|
|
#
¿
May 27, 2011 05:10
|
|
|
fankey posted:Apparently I kicked the write-only property hornets nest. For what it's worth, I don't think there's any problem with the idea of a write-only property. It just seemed like a bad fit for what you described.
|
|
#
¿
May 27, 2011 08:27
|
|
|
Toady posted:Note that the existence of a @property declaration for a class doesn't mean the property has been declared to be key-value observable, because the class might not use accessors internally. The fact that synthesized methods follow KVC accessor naming conventions is incidental. I'd argue a class whose instances don't (appear to) use its own accessors is a bug that should be fixed, but it's certainly fair to point this out about Apple's frameworks: it's not KVO unless the docs say so. (And this point is explicitly made in the KVO programming guide.)
|
|
#
¿
Jun 4, 2011 08:24
|
|
|
|
| # ¿ Apr 29, 2024 08:50 |
|
|
Bob Morales posted:Anyone have ideas (or even have this problem) on preventing peoples fingers from getting 'lost' on the touch screen in games? I'm not sure what you're asking, but maybe you could set the actions for the buttons from 'touch up inside' to 'touch down inside'?
|
|
#
¿
Jun 4, 2011 19:56
|
|