|
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. 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 |
|
|
# ? Jun 3, 2024 21:52 |
|
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. 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 |
|
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 |
|
I'm just repeating what I recall, not trying to throw shade . 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 |
|
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 |
|
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 |
|
Because one person's competitive, driven environment is another's toxic, abusive workplace
|
# ? Jul 3, 2017 09:30 |
|
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 |
|
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 |
|
tl;dr: If you are interested in making Apple dev tools better you should come work with us.
|
# ? Jul 3, 2017 19:43 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
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. 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 |
|
That's interesting. Is it actually required, or are you optimizing something? Do you have an example?
|
# ? Jul 4, 2017 15:03 |
|
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:
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:
You forgot (?) about @encode somewhere along the way. The alternative... isn't nice
|
# ? Jul 4, 2017 15:58 |
|
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. 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 |
|
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 |
|
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 |
|
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 |
|
hackbunny posted:Let's see, from the codebase I'm working on: 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] 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 |
|
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 |
|
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 |
|
I don't know GamePlayKit myself, but have you watched the WWDC session?
|
# ? Jul 6, 2017 23:20 |
|
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 |
|
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 |
|
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:
Luigi Thirty fucked around with this message at 07:05 on Jul 10, 2017 |
# ? Jul 10, 2017 07:03 |
|
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. 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 |
|
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 likeObjective-C code:
Objective-C code:
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 |
|
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 |
|
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 |
|
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 |
|
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 |
|
|
# ? Jun 3, 2024 21:52 |
|
eschaton posted:Counterpoint: The way Foundation has historically done initialization is really good and makes for very flexible code over the long term. 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 |