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

«‹›354 »

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

carry on then posted:

The most recent article I saw (can't remember where) seemed to say there was a large degree of competitiveness and you should probably be a marathon runner or something to fit in because most people have some sort of competitive hobby outside of work. They reported that long hours weren't the norm, but high levels of productivity were expected.

That's just my recollection though.

There are articles specifically about the employee culture on the Xcode team? That have better information than a couple of people who've been on the Xcode team for 9+ years?

There are certainly some things about Apple that, in my experience, are fairly pervasive across the company. That level of personal interest is not one of them; I'm not sure I know any teams that are personally competitive like that, much less groups or departments. Just trust me that Developer Tools is not exactly brimming over with marathon runners.

# ? Jul 2, 2017 21:51

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 13:36

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

carry on then posted:

The most recent article I saw (can't remember where) seemed to say there was a large degree of competitiveness and you should probably be a marathon runner or something to fit in because most people have some sort of competitive hobby outside of work. They reported that long hours weren't the norm, but high levels of productivity were expected.

That's just my recollection though.

I can�t speak to other teams but DevTools is professional and collaborative. I would say Apple expects your A game and no one is shy about pointing out when something isn�t good, but I haven�t seen anyone being a jerkass about it. I�d say people aren�t very defensive either. I find it pleasant to be in an environment where everyone is pushing for the best product without being a jerk.

# ? Jul 2, 2017 22:07

Mikey-San: Nov 3, 2005; I'm Edith Head!

Echoing what rjmccall, Simulated, and eschaton said. DevTools is a very professional environment staffed and run by competent adults who don't care whether you run the Barkley Marathons or whatever in your spare time. I worked in the macOS org for a long time prior to DT and it's the same there, too.

# ? Jul 3, 2017 02:48

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

I'm just repeating what I recall, not trying to throw shade :shrug:

. And I assume the article came from second hand reports a bunch of people from all over the place, so not just your team.

# ? Jul 3, 2017 03:47

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Apple has lots of and lots of employees on lots and lots of teams, so it would be surprising if there were none with a pile of hypercompetative marathon runners.

# ? Jul 3, 2017 06:21

Doctor w-rw-rw-: Jun 24, 2008

I hear Facebook employees also like to move fast

Seriously though, why are we debating the running habits of Apple employees again?

# ? Jul 3, 2017 08:46

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

Because one person's competitive, driven environment is another's toxic, abusive workplace

# ? Jul 3, 2017 09:30

Hughlander: May 11, 2005

hackbunny posted:

Because one person's competitive, driven environment is another's toxic, abusive workplace

Which has what to do with iOS/OSX development? I mean I could see it un the unironic Agilefall thread but not here.

# ? Jul 3, 2017 18:32

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

Someone asked what the stereotypes of working at Apple were and I relayed the last I had remembered reading. Discussion followed.

# ? Jul 3, 2017 18:46

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

tl;dr: If you are interested in making Apple dev tools better you should come work with us.

# ? Jul 3, 2017 19:43

Luigi Thirty: Apr 30, 2006; Emergency confection port.

I want to start writing toy iOS apps on my MBA since I've got a lot of spare time while job hunting. I know C and friends (and OS 8-era APIs!) but haven't used Objective-C or Swift. Which should I focus on when learning how modern Mac stuff works?

# ? Jul 3, 2017 21:43

Doctor w-rw-rw-: Jun 24, 2008

Simulated posted:

tl;dr: If you are interested in making Apple dev tools better you should come work with us.

Or with Facebook, where we stress test iOS dev to the max then build infra around improving that.

# ? Jul 3, 2017 21:46

Echo Video: Jan 17, 2004

Doctor w-rw-rw- posted:

Or with Facebook, where we stress test iOS dev to the max then build infra around improving that.

we get it

# ? Jul 3, 2017 22:01

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

Luigi Thirty posted:

I want to start writing toy iOS apps on my MBA since I've got a lot of spare time while job hunting. I know C and friends (and OS 8-era APIs!) but haven't used Objective-C or Swift. Which should I focus on when learning how modern Mac stuff works?

Start with Objective C IMO, Swift is good but all the iOS frameworks are written in and for Objective C. Swift can interface with them no problem for the most part, but you'll basically be learning two languages: Swift itself, and Objective C by way of the Swift-Objective C bridge

# ? Jul 3, 2017 22:19

Kallikrates: Jul 7, 2002; Pro Lurker

I don't think you would be learning objc anyways. A swift module interface looks like swift, and all those SDK's bridge. Do whatever makes you comfortable. The learning curve for cocoa dev is the platform and its quirks. An experienced developer can pick up enough objc or swift to get comfortable hammering away at the platform in a short time.

Things to keep in mind apple sample code recently has only been released in Swift, also there is an overabundance of out of date non compiling swift samples out there. The ideas are the same and for the out of date issue you'll end up translating those ideas in to objc or swift regardless.

# ? Jul 3, 2017 22:32

brap: Aug 23, 2004; Grimey Drawer

Regardless of the language you pick, I suggest you seek out tutorials that are about code-only UI and shun Interface Builder/Storyboards 100%. That will put you in a much happier place once your toy apps grow beyond very low levels of complexity.

# ? Jul 3, 2017 22:34

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

hackbunny posted:

Start with Objective C IMO, Swift is good but all the iOS frameworks are written in and for Objective C. Swift can interface with them no problem for the most part, but you'll basically be learning two languages: Swift itself, and Objective C by way of the Swift-Objective C bridge

Actually, people coming to iOS fresh tend to have less trouble with that than you'd think, at least in our experience. They do eventually tend to need to learn Objective-C, and maybe even eventually non-ARC Objective-C, but not all at once, and the benefits of progressive disclosure are real.

It also helps that they're generally starting from a newer version of Swift; the SDK's presentation in Swift has gotten more and more idiomatic as time has gone on. (The improvements to Core Graphics especially are amazing.)

rjmccall fucked around with this message at 22:37 on Jul 3, 2017

# ? Jul 3, 2017 22:35

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

rjmccall posted:

(The improvements to Core Graphics especially are amazing.)

For real. I don�t know if the Swift 3 bridging stuff was made partially with CG in mind or if whoever's responsible for CG just embraced it enthusiastically but it�s shockingly good.

Also I feel like half the defers I write are to end a graphics context.

# ? Jul 3, 2017 23:00

Doc Block: Apr 15, 2003; Fun Shoe

fleshweasel posted:

Regardless of the language you pick, I suggest you seek out tutorials that are about code-only UI and shun Interface Builder/Storyboards 100%. That will put you in a much happier place once your toy apps grow beyond very low levels of complexity.

Alternately, ignore the people who insist on doing everything in code. Unless you enjoy typing, because there'll be a lot of code to write. Especially when autolayout constraints and size classes become involved.

Sooner or later you'll have to do some UI stuff in code, so it'll be important to have a passing familiarity with it, but do as little as possible, and only when needed.

# ? Jul 3, 2017 23:44

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

rjmccall posted:

Actually, people coming to iOS fresh tend to have less trouble with that than you'd think, at least in our experience. They do eventually tend to need to learn Objective-C, and maybe even eventually non-ARC Objective-C, but not all at once, and the benefits of progressive disclosure are real.

It also helps that they're generally starting from a newer version of Swift; the SDK's presentation in Swift has gotten more and more idiomatic as time has gone on. (The improvements to Core Graphics especially are amazing.)

Maybe my work on iOS is atypical but when I work in Swift I find myself forced to use Unsafe this and Unsafe that all the time

# ? Jul 4, 2017 08:49

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

That's interesting. Is it actually required, or are you optimizing something? Do you have an example?

# ? Jul 4, 2017 15:03

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

Let's see, from the codebase I'm working on:

All out arguments are rendered in Swift as UnsafeMutablePointer, and it wasn't immediately obvious that I could just use unary &
KVO requires unpacking an UnsafeMutableRawPointer in the callback
Calling SCNetworkReachabilityCreateWithAddress with an "any" address is nothing short of byzantine:

Swift code:

        var nullAddress = sockaddr_in()
        
        nullAddress.sin_len = UInt8(exactly: MemoryLayout.stride(ofValue: nullAddress))!
        nullAddress.sin_family = sa_family_t(exactly: AF_INET)!
        
        reachability = withUnsafePointer(to: &nullAddress) {
            $0.withMemoryRebound(to: sockaddr.self, capacity: 1) {
                SCNetworkReachabilityCreateWithAddress(nil, $0)
            }
        }

Maybe I was just unfamiliar with Swift when I wrote that code and it could be done in an easier way

Creating a reference counted SCNetworkReachabilityContext in Swift (and receiving it from the callback set with SCNetworkReachabilitySetCallback) is an interesting exercise in self-harm
I don't remember why I generate random data by using NSMutableData and arc4random_buf but I seem to remember that using a mutable Data object was ridiculously involved
The less said about C structures with embedded arrays, the better:

Swift code:

        return
            lhs.data.0 == rhs.data.0 &&
            lhs.data.1 == rhs.data.1 &&
            lhs.data.2 == rhs.data.2 &&
            lhs.data.3 == rhs.data.3 &&
            lhs.data.4 == rhs.data.4 &&
            lhs.data.5 == rhs.data.5 &&
            lhs.data.6 == rhs.data.6 &&
            lhs.data.7 == rhs.data.7 &&
            lhs.data.8 == rhs.data.8 &&
            lhs.data.9 == rhs.data.9 &&
            lhs.data.10 == rhs.data.10 &&
            lhs.data.11 == rhs.data.11

CVarArg

You forgot (?) about @encode somewhere along the way. The alternative... isn't nice

# ? Jul 4, 2017 15:58

TacoHavoc: Dec 31, 2007; It's taco-y and havoc-y...at the same time!

Doc Block posted:

Alternately, ignore the people who insist on doing everything in code. Unless you enjoy typing, because there'll be a lot of code to write. Especially when autolayout constraints and size classes become involved.

Sooner or later you'll have to do some UI stuff in code, so it'll be important to have a passing familiarity with it, but do as little as possible, and only when needed.

I'm a pretty bad computer toucher but I made the jump from embedded code to iOS, first in objective C then swift. I would agree with this statement. Use the interface builder to get you off the ground, then when you start getting frustrated by the constraints or want to make something more fancy make the jump to UI in code. I found it better to take layout in code away from the initial difficulty curve.

# ? Jul 4, 2017 16:06

PT6A: Jan 5, 2006; Public school teachers are callous dictators who won't lift a finger to stop children from peeing in my plane

TacoHavoc posted:

I'm a pretty bad computer toucher but I made the jump from embedded code to iOS, first in objective C then swift. I would agree with this statement. Use the interface builder to get you off the ground, then when you start getting frustrated by the constraints or want to make something more fancy make the jump to UI in code. I found it better to take layout in code away from the initial difficulty curve.

This is true. However, gently caress Storyboards and nuke them from orbit, IMO. NIB files are fine, but storyboards end up as terrible masses of complexity for anything non-trivial. Learn how to work without them, and then if you do decide to use them, keep it for basic stuff only.

# ? Jul 4, 2017 18:08

brap: Aug 23, 2004; Grimey Drawer

Once your team size is larger than one and you need to do any of:

- merge your work with other people's work
- use composition (i.e. reuse chunks of UI) in your app without adding fragile assumptions (Oh, I'll just insert this reusable component in code into position 2 in this stack view because that's how many subviews over it should be in the XIB right now) or just generally confusing mixed layout work between XIBs and code
- rename or delete views without needing to do the same action in parallel in your XIB and source code
- change the type of a view, for example from UILabel to UITextView, while preserving the constrants on it
- work on a large view controller without Xcode bogging down horrendously when you open it
- make any kind of maintainable color theme

you're better off with UI in code.

If I could go back and start learning iOS again from scratch, I would just bite the bullet and learn to do UI in code as soon as possible. Especially now that anchors and stack views are a thing, it's relatively pleasant and productive. Maybe do your first calculator or counter app with an XIB and then move on to a more maintainable and scalable approach.

brap fucked around with this message at 21:05 on Jul 4, 2017

# ? Jul 4, 2017 21:02

dc3k: Feb 18, 2003; what.

IB is great for quickly prototyping a UI, but more and more I'm moving towards playgrounds for this since you don't have to re-create the view afterwards in code

edit; layout anchors are the bee's knees

dc3k fucked around with this message at 21:22 on Jul 4, 2017

# ? Jul 4, 2017 21:20

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

hackbunny posted:

Let's see, from the codebase I'm working on:

All out arguments are rendered in Swift as UnsafeMutablePointer, and it wasn't immediately obvious that I could just use unary &

Yeah, I think a lot of people miss this.

hackbunny posted:

KVO requires unpacking an UnsafeMutableRawPointer in the callback

Hmm.

hackbunny posted:

Calling SCNetworkReachabilityCreateWithAddress with an "any" address is nothing short of byzantine:[code=swift]
Creating a reference counted SCNetworkReachabilityContext in Swift (and receiving it from the callback set with SCNetworkReachabilitySetCallback) is an interesting exercise in self-harm

Networks stuff is definitely something we should prioritize. I think it's being held up by not having a good concurrency system yet.

hackbunny posted:

I don't remember why I generate random data by using NSMutableData and arc4random_buf but I seem to remember that using a mutable Data object was ridiculously involved

You should be able to pass an &array as a UnsafeMutableRawPointer. Of course, you'll need to make sure there's space in it first.

hackbunny posted:

The less said about C structures with embedded arrays, the better:

It's on the list. Although you *can* just add an static inline function to your bridging header if this stuff is easier to write in C.

hackbunny posted:

CVarArg

You have to add your own conformances to CVarArg? That is surprising.

hackbunny posted:

You forgot (?) about @encode somewhere along the way. The alternative... isn't nice

In what sense? We really don't support that kind of reflection on non-@objc methods.

# ? Jul 4, 2017 22:08

hackbunny: Jul 22, 2007; I haven't been on SA for years but the person who gave me my previous av as a joke felt guilty for doing so and decided to get me a non-shitty av

rjmccall posted:

You have to add your own conformances to CVarArg? That is surprising.

Oh no I just fought with it a lot when I started writing my first Swift class ever (the app's logger), now I steer clear of it whenever possible. The fact that Swift ignores format string annotations doesn't help

rjmccall posted:

In what sense? We really don't support that kind of reflection on non-@objc methods.

@encode strings are also used in NSNumber/NSValue

# ? Jul 6, 2017 20:40

Luigi Thirty: Apr 30, 2006; Emergency confection port.

I have a GameplayKit question. I�m writing a simple 8x8 board game (in Objective-C) while I�m learning all this iOS stuff.

I have a GKStateMachine with a Player1TurnState and a Player2TurnState. GameScene has a handleTouchedTile method that does some game logic processing when a board tile is touched.

It seems like I�m not supposed to just have a switch statement in handleTouchedTile that checks the game�s current state and does player 1 or 2 actions (currently just check for valid moves for the current player) depending. I�m not sure how to put that logic in the state machine subclasses though. How should this be implemented?

# ? Jul 6, 2017 23:09

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

I don't know GamePlayKit myself, but have you watched the WWDC session?

# ? Jul 6, 2017 23:20

Rudest Buddhist: May 26, 2005; You only lose what you cling to, bitch.; Fun Shoe

One of the hackingwithswift tutorials has pretty good overview of the AI side of GameplayKit. You can check it out here: https://www.hackingwithswift.com/read/34/overview

# ? Jul 7, 2017 05:44

LP0 ON FIRE: Jan 25, 2006; _{beep boop}

I'm working on an older Obj-C project with ARC enabled, and I'm having so much trouble trying to follow what's leaking. First of all, Instrument's Leaks tool is not following along when I hit the record button. It does not show anything on the graph until I hit stop. Secondly, I swear I remember being able to hit the little sideways arrow and navigating to something that gives more detail on the list. It does nothing now. Maybe because I stopped it?

Aside from adding in CGPathRelease on paths made with CGPathCreateMutable because ARC doesn't release some Core Graphics stuff, I'm not sure what else there is.

edit: I hope this is what it was, but I found that I was definitely not removing my SKEmitterNodes! I set up an action to remove them and it seems to be working nicely.

LP0 ON FIRE fucked around with this message at 19:33 on Jul 9, 2017

# ? Jul 9, 2017 18:46

Luigi Thirty: Apr 30, 2006; Emergency confection port.

I have a maybe dumb question. I wrote an extension init method for SKNode that reduces the amount of boilerplate needed to set one up.

code:

- (instancetype) initWithName:(NSString *)name withPosition:(CGPoint)position withParent:(SKScene *)scene {
	
	self = [[SKNode alloc] init];
	if(!self)
		return nil;
	
	self.name = name;
	self.position = position;
	
	if(scene != nil) {
		[scene addChild:self];
	}
	
	return self;
}

I'd like to be able to use it with SKShapeNode and SKLabelNode as well but as you can see it's creating an SKNode object. Is there a way to init an object of whatever subclass is passed in instead or do I have to duplicate the initializer for every node subclass I want to use it with?

Luigi Thirty fucked around with this message at 07:05 on Jul 10, 2017

# ? Jul 10, 2017 07:03

Simulated: Sep 28, 2001; Lowtax giveth, and Lowtax taketh away.; College Slice

Luigi Thirty posted:

I have a maybe dumb question. I wrote an extension init method for SKNode that reduces the amount of boilerplate needed to set one up.
code:
- (instancetype) initWithName:(NSString *)name withPosition:(CGPoint)position withParent:(SKScene *)scene {
	
	self = [[SKNode alloc] init];
	if(!self)
		return nil;
	
	self.name = name;
	self.position = position;
	
	if(scene != nil) {
		[scene addChild:self];
	}
	
	return self;
}
I'd like to be able to use it with SKShapeNode and SKLabelNode as well but as you can see it's creating an SKNode object. Is there a way to init an object of whatever subclass is passed in instead or do I have to duplicate the initializer for every node subclass I want to use it with?

That is not how to do subclassing. You may be leaking memory (I'd have to check exactly what ARC does when you overwrite the self pointer with a different allocation). You should be calling self = [super init], in which case you'll get the correct subclass of SKNode.

# ? Jul 10, 2017 07:25

Doc Block: Apr 15, 2003; Fun Shoe

Factory functions aren't really idiomatic in Objective-C or Swift. It will probably be less work to just add your custom init methods to the other classes. However, if SKShapeNode and SKLabelNode inherit from SKNode, then maybe just add a category to the SKNode class that does something like

Objective-C code:

// call after initialization
- (void)setName:(NSString *)name position:(CGPoint)position parent:(SKScene *)scene
{
    self.name = name;
    self.position = position;
    if(scene) {
        [scene addChild:self];
    }
}

Also, redo your init method

Objective-C code:

- (instancetype)initBlahBlah
{
    self = [super initDesignatedInitializerBlahBlah];
    if(self) {
        // do stuff
    }

    return self;
}

so that you aren't overwriting self and always get the correct class.

edit: beaten about the init method

Doc Block fucked around with this message at 07:52 on Jul 10, 2017

# ? Jul 10, 2017 07:29

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

The ObjC initializer design is really screwed up, basically because it turns out that initialization is one of those things that turns out massively better if you actually have some sort of language support. Unfortunately, it's bad enough that it's also messed up the Swift initializer design.

In any language with class inheritance, it makes sense to contrast "complete" initialization with "subobject" initialization.

Complete initialization produces a complete object of some class. Construction always starts by invoking a complete initializer. Typically, a complete initializer allocates an object of a class and then calls a subobject initializer for that class, but it's also sensible for a complete initializer to delegate to another complete initializer for the class. It's reasonable for a complete initializer to end up producing an object of a subclass, or to return an existing object of the class. It's reasonable for there to be an inherited requirement that all subclasses of a particular class must provide a complete initializer with a particular signature. Whether a complete initializer can reasonably be inherited in the normal OO sense, as an implementation, depends on the specifics of that implementation: for example, if it delegates to an inherited requirement for a complete initializer, it is safe to inherit, but if it constructs a new object of a specific class, it is not safe to inherit.

Subobject initialization fills in the parts of an uninitialized object that correspond to a class and its superclasses. A subobject initializer can reasonably delegate to one of its peer subobject initializers, or it can fill in its own fields and delegate to its superclass's subobject initializer, but it can never sensibly delegate to a complete initializer. A subobject initializer does not allocate the object. A subobject initializer cannot construct a subclass object. A subobject initializer cannot generally be inherited. It does not make sense to have an inherited requirement for a subobject initializer.

Objective-C conflates these two concepts in a terribly confusing way, and then implements them on top of an inadequate language mechanism, and then everybody talks about them in an even more confusing way. The allocation aspect of complete initialization is inlined into the original caller (when you call +alloc), which then has to be worked around when classes want to do something more clever with allocation. -init methods can be either subobject initializers (generally called "delegate" initializers) or complete initializers (generally called "convenience" initializers), and you just have to know. Either way, they are always inherited, and your program will just misbehave if you use one in a way that you're not supposed to. A lot of otherwise sensible people seem to feel that all delegate initializers are supposed to be inherited requirements, even though that obviously makes no sense. And core libraries do all sorts of crazy poo poo like provide subobject initializers that replace the object they're initializing when you super-delegate up to them and everything else is just supposed to work around that fact.

It would be a far better design if construction started by calling a +new method, and those were always complete initializers and just weren't inherited unless you declared them to be, and the +new method could create an object and call -init on it if it wanted to, and -init methods were subobject initializers and were just never inherited. Unfortunately, there's no way to prevent inheritance in ObjC. You'd also have to manually implement a really obvious +new function that just forwarded its arguments for every initializer you wanted to provide in the common case where you want to allow a subobject initializer to be used as a complete initializer for that specific type. It's just a mess.

# ? Jul 10, 2017 08:41

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Counterpoint: The way Foundation has historically done initialization is really good and makes for very flexible code over the long term.

Prior to ARC and the static analyzer, these were purely framework rather than language conventions. In particular, having +alloc, -init, and -dealloc be just methods with overridable behavior has enabled an enormous amount of flexibility over the years.

Using +new and +free methods was tried for a few years too in NeXT's original frameworks. (As in Stepstone's libraries, and Smalltalk before ObjC.) But they were superseded pretty quickly by the Foundation two-phase initialization coupled with Blaine's memory management scheme (autorelease pools) because combining object graph ownership and memory management turned out to be a very hard problem. (It still is to this day, but at least with reference counting it's easier to share ownership with some semblance of safety.)

# ? Jul 10, 2017 09:15

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Also one of the best things about Objective-C is that all methods are inherited and (other than he automatic invitation of +load and +initialize, and allowing the elision of [super dealloc]; in ARC) there are no special dispatch behaviors. This makes for very predictable code, even if it's not the absolute most efficient, as well as gives great flexibility for implementing the kinds of hacks and patches that are sometimes necessary to ship (or debug) large systems.

# ? Jul 10, 2017 09:21

Doh004: Apr 22, 2007; Mmmmm Donuts...

Luigi Thirty posted:

I want to start writing toy iOS apps on my MBA since I've got a lot of spare time while job hunting. I know C and friends (and OS 8-era APIs!) but haven't used Objective-C or Swift. Which should I focus on when learning how modern Mac stuff works?

hackbunny posted:

Start with Objective C IMO, Swift is good but all the iOS frameworks are written in and for Objective C. Swift can interface with them no problem for the most part, but you'll basically be learning two languages: Swift itself, and Objective C by way of the Swift-Objective C bridge

Please don't do this. Start off on Swift. I understood the holdouts 2 years ago, but it's well past the time to move on - particularly with new things. I get needing to work on existing codebases and sticking to the language, but Swift is definitely good now. Plenty of things to make better over time but enough is enough.

# ? Jul 10, 2017 14:59

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 13:36

rjmccall: Sep 7, 2007; no worries friend; Fun Shoe

eschaton posted:

Counterpoint: The way Foundation has historically done initialization is really good and makes for very flexible code over the long term.

Prior to ARC and the static analyzer, these were purely framework rather than language conventions. In particular, having +alloc, -init, and -dealloc be just methods with overridable behavior has enabled an enormous amount of flexibility over the years.

Using +new and +free methods was tried for a few years too in NeXT's original frameworks. (As in Stepstone's libraries, and Smalltalk before ObjC.) But they were superseded pretty quickly by the Foundation two-phase initialization coupled with Blaine's memory management scheme (autorelease pools) because combining object graph ownership and memory management turned out to be a very hard problem. (It still is to this day, but at least with reference counting it's easier to share ownership with some semblance of safety.)

You are conflating things because they happened around the same time, as if a better initialization scheme would somehow prevent the use of autorelease pools and reference counting. There are nice things about the conceptual simplicity of ObjC, but initialization is absolutely one of those places where that simplicity has completely led it astray and produced far more emergent complexity than a simpler scheme with just a bit of language support would have.

# ? Jul 10, 2017 16:44

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

«‹›354 »