|
Doc Block posted:For iOS you always need to sign. Are you talking about the black boxes in the screenshots? That was just me editing the screenshot to subvert the NSA - they are actually set to the same Team and Bundle as my main app. Is there a straight forward way to convert the dylib project to a Framework?
|
#
?
Dec 3, 2020 20:34
|
|
|
|
| # ? May 15, 2024 11:25 |
|
|
Ohhh... that's what I get for phoneposting  edit: I would probably just make a new Framework target, and add files to it however you need them. Then you can have your app use that instead of the dylib and no custom include directories or any of that. Doc Block fucked around with this message at 21:56 on Dec 3, 2020 |
|
#
?
Dec 3, 2020 21:51
|
|
|
Doc Block posted:Ohhh... that's what I get for phoneposting Thanks for pointing me in that direction - I was able to create a Framework as a child of my project and with a little finagling got everything uploaded to appstoreconnect and get it from TestFlight. I do have a couple of questions since I don't really understand Frameworks. The ANTLR4 source is huge and when it's part of the main project the whole thing builds on every Archive which on my Air takes over 5 minutes. It seems like the best thing would be to remove it from my main workspace, build it separately and then reference the Framework so I only need to rebuild if the Framework source changes. I can open up the Framework project in another copy of Xcode and drag it in but then I either get a 'Framework not found error' when Archiving for the App Store or 'Building for iOS Simulator, but the linked framework was build for iOS'. So either the way I'm building the framework is wrong or the way I'm including it is. The other thing that's odd - when I had the framework as part of the main project I had to select 'Embed & Sign' on that framework to get it up into appstoreconnect. What's odd is that I have other frameworks build locally ( using Carthage, another piece of magic I don't understand... ) and those are set to 'Not Embed' and work fine. What's different between the way Carthage is bringing in frameworks vs what I was doing? Tried following this https://medium.com/allatoneplace/writing-custom-universal-framework-in-xcode-9-and-ios-11-7a63a2ce024a and had no luck. The script didn't generate a shortcut in the project folder and the resultant build archive didn't contain any of the framework. fankey fucked around with this message at 22:27 on Dec 3, 2020 |
|
#
?
Dec 3, 2020 22:12
|
|
|
Generally, what I do is: 1)build the framework 2)in Finder, copy it to the same folder as YourProject.xcodeproj 3)in the build stuff for your project, under the General tab, in the Frameworks, Libraries, and Embedded Content section, hit the +, hit Add Other..., and select the framework (make sure to select the one you copied to the same folder as your .xcodeproj). 4)Xcode should do the rest. Make sure you undo any custom include directory stuff in the build settings. edit: as to Carthage, I don't use it so I have no idea what it's doing differently. AFAIK it's just a package manager that sets up an Xcode workspace for you with your app's dependencies' .xcodeproj included and set as a dependency for your app, right? I've never really bothered with Xcode workspaces. Doc Block fucked around with this message at 23:53 on Dec 3, 2020 |
|
#
?
Dec 3, 2020 23:44
|
|
|
Doc Block posted:edit: as to Carthage, I don't use it so I have no idea what it's doing differently. AFAIK it's just a package manager that sets up an Xcode workspace for you with your app's dependencies' .xcodeproj included and set as a dependency for your app, right? I've never really bothered with Xcode workspaces. Carthage doesn't do anything to your project or workspace, and a workspace isn't required with Carthage (it is for Cocoapods, which will create a workspace to wrap your project). Carthage will build frameworks shared schemes of Xcode projects inside Git repos you specify in the Cartfile. You can then drag the framework into your project or workspace and then include them in your target. Then you have to do shenanigans to ensure you don't upload simulator binaries to the store because gently caress you Generally these days SPM is so much better if you can use it, but there are some things that can't be done with it and it is frustrating if you need to build something with Xcode 11 still but want Firebase, for example, which uses SPM but requires Xcode 12.
|
|
#
?
Dec 4, 2020 03:22
|
|
|
What's up with this pbxproj file? Why does Xcode have to be weird instead of just using the file system to organize the project? Had they just never considered the idea that apps might be built by teams of people?
|
|
#
?
Dec 8, 2020 18:06
|
|
|
So you're not grateful for the crash course in modified NeXTSTEP property list syntax?
|
|
#
?
Dec 8, 2020 19:53
|
|
|
I'm still busy trying to figure out why opening a .xib file modifies it
|
|
#
?
Dec 8, 2020 22:09
|
|
|
Xcode project files are really lovely. At one point I even used a utility for my project which would generate the Xcode project from a script so I wouldn’t have to version control and handle conflicts in that mess. Now the script was pretty bad too, but it was pretty much a matter of picking your poison.
|
|
#
?
Dec 8, 2020 22:32
|
|
|
brap posted:Xcode project files are really lovely. At one point I even used a utility for my project which would generate the Xcode project from a script so I wouldn’t have to version control and handle conflicts in that mess. We started using SPM for this (and some tools to modify the project afterwards to make it actually run as an iOS app). It seemed like a cool idea but the generate xcodeproj command is being deprecated so we’re going to have to figure something else out.
|
|
#
?
Dec 9, 2020 04:02
|
|
|
prom candy posted:What's up with this pbxproj file? Why does Xcode have to be weird instead of just using the file system to organize the project? Had they just never considered the idea that apps might be built by teams of people? This is putting the cart before the horse. The file format can be traced back to Project Builder. And FWIW when Xcode was starting life some very loud and opinionated people insisted they needed to be able to organize things without regard for the filesystem. They're probably even correct, I'm not sure the compiler and build infrastructure at the time even had headermap support.
|
|
#
?
Dec 9, 2020 05:03
|
|
|
Simple things should be easy and hard things should be possible. So the fact that there isn’t a convention that provides sane defaults which dramatically simplify projects and reduce the number and severity of merge conflicts is a real shortcoming. Also IIRC there are so many freaking guids in the format as it exists which makes following what the file is doing rather painful. Anything that is version controlled will have to be compared and de-conflicted in its raw form, and it’s so important to keep those scenarios in mind when developing a text file format. That was likely less of a concern when the format is developed, but that just shows its age.
|
|
#
?
Dec 9, 2020 07:42
|
|
|
It's gotten better over time. I vaguely remember the object IDs were a lot more random than they are now, and could maybe change inexplicably? Or maybe that was CocoaPods-induced. It's not a complicated format, but dealing with conflicts by hand can get real annoying as there's a lot of pointers to pointers to objects.
|
|
#
?
Dec 9, 2020 07:53
|
|
|
prom candy posted:What's up with this pbxproj file? Why does Xcode have to be weird instead of just using the file system to organize the project? Had they just never considered the idea that apps might be built by teams of people? Or maybe it turns out there are also downsides to using the filesystem to organize projects, particularly large and complex ones.
|
|
#
?
Dec 9, 2020 08:47
|
|
|
brap posted:Simple things should be easy and hard things should be possible. So the fact that there isn’t a convention that provides sane defaults which dramatically simplify projects and reduce the number and severity of merge conflicts is a real shortcoming. Also IIRC there are so many freaking guids in the format as it exists which makes following what the file is doing rather painful. Maybe the people involved in its design actually understood all those things, and it’s actually designed to minimize merge conflicts by organizing things in sections, sorting the instances in each section by PBXGlobalID, and so on. If you rearrange the file to be mostly-hierarchical and mostly-ID-free (you still have to have some IDs to make cross-graph links, to deal with things like build phase membership) you’ll actually get more conflicts in practice than you do today. The difference is that the conflicts will probably be perceived as more tractable by people who give up as soon as they see an ID instead of a name.
|
|
#
?
Dec 9, 2020 08:55
|
|
|
pokeyman posted:It's gotten better over time. I vaguely remember the object IDs were a lot more random than they are now, and could maybe change inexplicably? Or maybe that was CocoaPods-induced. They’ve always been random, but they should persist and not change. If object IDs in a project are changing out from under you, then that’s likely something other than Xcode. Or were you talking about in xib files? They should also be stable, since the IDs are used for localization.
|
|
#
?
Dec 9, 2020 08:58
|
|
|
eschaton posted:They’ve always been random, but they should persist and not change. If object IDs in a project are changing out from under you, then that’s likely something other than Xcode. I was probably thinking of something unhelpful that CocoaPods used to do. It was years ago at any rate.
|
|
#
?
Dec 9, 2020 17:12
|
|
|
eschaton posted:If you rearrange the file to be mostly-hierarchical and mostly-ID-free (you still have to have some IDs to make cross-graph links, to deal with things like build phase membership) you’ll actually get more conflicts in practice than you do today. The difference is that the conflicts will probably be perceived as more tractable by people who give up as soon as they see an ID instead of a name. Sure, but that's not going far enough. The design that results in the least merge conflicts is the design that minimizes the amount of crap you have to write. Introduce the ability to say "use the files matched by these globs as the source files for my project" as so many current project systems do--maven, dotnet core, and so on, with a reasonable default where sources placed in a conventional location relative to the project are "just included" the way 95% of use cases require, and the ability to opt out of that default if it doesn't work for your use case. I'm trying to convince myself that GUIDs are necessary or desirable for Apple's project system. But I just can't fathom it. A file path refers to a single thing. The idea of automatically associating each one with a GUID and referring to the GUID instead of the path is astonishing to me. I wonder if any other widely adopted project format does this.
|
|
#
?
Dec 9, 2020 17:45
|
|
|
pokeyman posted:I was probably thinking of something unhelpful that CocoaPods used to do. It was years ago at any rate. Yes, CocoaPods used to do some very incorrect things with project files. They now do only mildly incorrect things and mostly don't gently caress with the project file in gratuitous ways. eschaton posted:Maybe the people involved in its design actually understood all those things, and it’s actually designed to minimize merge conflicts by organizing things in sections, sorting the instances in each section by PBXGlobalID, and so on. Once I understood why pbxproj files are structured the way they are I stopped thinking that the designers of it were idiots, but the fact still remains that in practice it's the most obnoxious project file format I've ever worked with. Despite being designed with the intention of reducing conflicts it fails to do so, and when you have conflicts more complicated than "two people added and/or removed some files" they become difficult enough to resolve that most people just give up and redo the work. We have podspecs, swift packages, cmake projects and xcode projects which all build the same codebase (and none of them use globs FWIW) so I get to compare very directly how obnoxious each of them are. Xcode projects are the very clear losers, and the fact that there were some ideas that seemed good at the time that went into designing them doesn't change that.
|
|
#
?
Dec 9, 2020 18:11
|
|
|
We are very well aware of the issues with pbxproj files and merge conflicts; there is no need to sell us on the problem. As the last user of the OpenStep ASCII plist format we are also well aware of the quirks of the file format.
|
|
#
?
Dec 10, 2020 13:44
|
|
|
One thing you do have to understand though is that things can’t just be changed around without also offering a migration path—in particular, one that doesn’t need everything reorganized on disk. That might be OK to ask of new projects (see also: Swift Package Manager) but it’s a non-starter for quite a few existing ones. Similarly, just saying “instead of explicit references, everything is incorporated by fnmatch(3) pattern now” gets you either broken projects (because now they incorporate stuff they previously didn’t) or projects that have even more painful lists of sources than today (because almost every project is a big list of exceptions to the rules). And then there’s the need to represent things like multi-target membership, which isn’t well represented in a lot of other project models, but is critical to quite a few Xcode projects. (For both good and bad or unfortunate reasons.) I’m not saying “better things aren’t possible” or “your complaints are invalid,” and it’s not like I can talk in any way about future plans. But I can say that it’s not a simple problem space, and it’s important to tread carefully to both preserve compatibility and ensure that any changes are themselves actual improvements—or at minimum don’t do something for short-term expedience that precludes long-term improvement.
|
|
#
?
Dec 12, 2020 07:31
|
|
|
I gotta say this autolayout stuff is pretty nifty, coming from web dev. Some stuff that's super annoying with CSS is dead simple here. Should I be using a UITableView pretty much any time I'm presenting data in rows? Like even if I have a form with a handful of hardcoded fields or a short list of hardcoded items? Are there any good books or resources for learning UIKit in general that aren't necessarily focused at beginner programmers?
|
|
#
?
Dec 13, 2020 15:22
|
|
|
prom candy posted:I gotta say this autolayout stuff is pretty nifty, coming from web dev. Some stuff that's super annoying with CSS is dead simple here. You should use a collection view for everything. 
|
|
#
?
Dec 13, 2020 17:38
|
|
|
Yeah if your deployment target allows for the new collection view layouts that resemble a table view, use that. Otherwise, table view forever. Even if you only have three hardcoded items today, when you end up with 50 tomorrow you'll be glad you started with a table view.
|
|
#
?
Dec 13, 2020 17:45
|
|
|
Why new collection view over table view?
|
|
#
?
Dec 13, 2020 18:11
|
|
|
pokeyman posted:Yeah if your deployment target allows for the new collection view layouts that resemble a table view, use that. Otherwise, table view forever. Even if you only have three hardcoded items today, when you end up with 50 tomorrow you'll be glad you started with a table view. Yeah we often just use table views (or collection views) at work do handle most scrolling needs. You can use scroll views with custom and/or stack views inside, but I’ve found it’s very hard to get right without autolayout complaining at run time or in interface builder about layout constraints. Then when you do get it right, it’s hard to add something else later, as you said. Usually a coworker adds a view to a stack view and either also adds constraints in a weird way (e.g. trying to constrain something inside a stack view to something outside the stackview’s parent scrollview) or they don’t understand if the view they’ve added has an intrinsic content size (or didn’t set it up properly to have one) and pick the “wrong” stack view distribution type. Edit: 101 posted:Why new collection view over table view? iOS 14 added a list layout type to CollectionView a that basically mimics a table view, but collection views can also be used to create much more complicated layouts as well, so you might as well just learn one instead of both (though in simple cases they are both very, very similar so it’s not hard to learn both). Pulcinella fucked around with this message at 19:06 on Dec 13, 2020 |
|
#
?
Dec 13, 2020 19:03
|
|
|
101 posted:Why new collection view over table view? Like Pulcinella said: collection views have (finally) gained a strict superset of a table view's capabilities, so there's really no reason to confine yourself to one kind of layout if you're writing new code. Pulcinella posted:Yeah we often just use table views (or collection views) at work do handle most scrolling needs. You can use scroll views with custom and/or stack views inside, but I’ve found it’s very hard to get right without autolayout complaining at run time or in interface builder about layout constraints. Then when you do get it right, it’s hard to add something else later, as you said. Usually a coworker adds a view to a stack view and either also adds constraints in a weird way (e.g. trying to constrain something inside a stack view to something outside the stackview’s parent scrollview) or they don’t understand if the view they’ve added has an intrinsic content size (or didn’t set it up properly to have one) and pick the “wrong” stack view distribution type. For me the reuse mechanism is key. I've had screens that end up a table view with seventeen rows each with a unique custom cell, and it just feels like an extra layer of boilerplate. Then again, I've also made stack view screens where I later wanted to stamp out a few copies of one of the arranged subviews, so I sympathize with the "assume you'll want cell reuse" mentality. The new (to Interface Builder, they've been in code longer) content and frame layout guides on scroll views make layout considerably more sensible. Though I often want to constrain content width to frame width and that currently requires code, can't do it directly in IB  And yeah, life gets easier when you use intrinsic sizes to work with the system, but it's apparently too easy to just set a hardcoded size constraint and call it a day. I know the design calls for a 54pt tall button, but how about we boop up the content insets to hit the target instead of adding a required constant height constraint, and then future-us won't hate present-us!
|
|
#
?
Dec 13, 2020 20:18
|
|
|
pokeyman posted:...then future-us won't hate present-us! Technical debt really is just a form of scam. Us in the future are the biggest rubes who will accept whatever poo poo we give them. By the time they figure it out we will be long gone!
|
|
#
?
Dec 13, 2020 22:47
|
|
|
My boss wants me to research what native resolution iPhone 11 and 12 capture at before it goes to the selected resolution your capturing at. For instance when you capture video at 4K 60 fps with your camera, what resolution does it start off with before it goes to 4K, if that makes any sense. The assumption is the capturing resolution is slightly higher. Or does it “see” the image at 1440x768 and then scale it digitally at 2K or 4K? I have no idea where I can find this.
Good Sphere fucked around with this message at 02:58 on Dec 15, 2020 |
|
#
?
Dec 15, 2020 02:45
|
|
|
the iPhone 11 and 12 back facing cameras each have a 12 megapixel resolution, according to Apple. This works out to 4K (4096 x 3072 = 12582912 pixels, aka 12 megapixels). Doesn’t mean that’s the raw pixel dimensions though Doc Block fucked around with this message at 04:09 on Dec 15, 2020 |
|
#
?
Dec 15, 2020 03:59
|
|
|
Doc Block posted:the iPhone 11 and 12 back facing cameras each have a 12 megapixel resolution, according to Apple. This works out to 4K (4096 x 3072 = 12582912 pixels, aka 12 megapixels). Thanks, I’m pretty convinced too. Going far back as 6s, I see that people are saying it records 4K natively, (but of course 6s would be the less tall version of 4K).
|
|
#
?
Dec 15, 2020 17:52
|
|
|
I'm having a really not fun time trying to manage the Apple Developer account which is the Account Holder. What's the right way to handle this? Presumably large companies have a good flow for managing the Account Holder that isn't hope one person's account details and phone number still work and that they can send you the login details and 2fa code or whatever. Assuming that every app has exactly one email+phone number that can both legally own the app and pop open the developer portal any time of day to accept a new agreement or do whatever admin task that only the Account Holder can do feels pretty dumb to me but maybe that's just because it's a pain in my rear end today.
awesomeolion fucked around with this message at 17:37 on Dec 16, 2020 |
|
#
?
Dec 16, 2020 17:33
|
|
|
awesomeolion posted:I'm having a really not fun time trying to manage the Apple Developer account which is the Account Holder. What's the right way to handle this? Presumably large companies have a good flow for managing the Account Holder that isn't hope one person's account details and phone number still work and that they can send you the login details and 2fa code or whatever. Assuming that every app has exactly one email+phone number that can both legally own the app and pop open the developer portal any time of day to accept a new agreement or do whatever admin task that only the Account Holder can do feels pretty dumb to me but maybe that's just because it's a pain in my rear end today. It's not great and there's really not many solutions because Apple want's account holders to be real people. The best you can do is fool it with a shared account, but most large orgs tend to avoid shared accounts because of security risks from what I've seen. In painful news my colleagues where working on a react native internal enterprise app and I'm now trying to set up build automation for them. To track versions they've been changing the bundle identifier and I kind of want to scream.
|
|
#
?
Dec 18, 2020 18:33
|
|
|
Retrogaming reverse engineering question. Actual Apple ][ question! Applesoft BASIC, specifically, the later version that actually understands floating-point numbers. I'm wondering why this experience point cap exists: code:And if they just wanted to store this as 3 bytes (that's what FN P(51), P(52), and P(53) are), they would cap at 2 ^ 24 - 1 instead; there's plenty of other capping at 2 ^ 8 -1 and 2 ^ 16 - 1. This does make a difference, since you may not be able to hit the game's level cap otherwise. This may be because floating-point variables (normal in BASIC) are being treated as if they have a 23-bit mantissa, which would have the purpose of always precisely representing experience. But I thought in Applesoft BASIC, they are 40-bit with a 31-bit mantissa, not 32-bit with a 23-bit mantissa? Is there some other reason I'm missing?
|
|
#
?
Dec 20, 2020 01:13
|
|
|
Boldor posted:Retrogaming reverse engineering question. The built-in Apple II floating point routines (written by the Woz himself) had a 24-bit mantissa (including sign). See http://www.6502.org/source/floats/wozfp3.txt. Applesoft BASIC was ported from Microsoft Basic... I can only speculate that Applesoft Basic didn't use the built-in floating point (which would explain the difference in precision), but the programmers of whatever game assumed that the Applesoft BASIC floating points worked the same way as the Apple II floating point.
|
|
#
?
Dec 20, 2020 02:38
|
|
|
KidDynamite posted:It's not great and there's really not many solutions because Apple want's account holders to be real people. The best you can do is fool it with a shared account, but most large orgs tend to avoid shared accounts because of security risks from what I've seen. I'm imagining Zucc having to 2fa into Facebook's developer account to accept the latest terms update... If they avoid shared accounts then they literally are messaging that one person who has 2fa setup to do the thing each time? That's hard to believe for some reason but I've never worked at a large org 
|
|
#
?
Dec 20, 2020 18:52
|
|
|
Bruegels Fuckbooks posted:The built-in Apple II floating point routines (written by the Woz himself) had a 24-bit mantissa (including sign). See http://www.6502.org/source/floats/wozfp3.txt. Applesoft BASIC was ported from Microsoft Basic... I can only speculate that Applesoft Basic didn't use the built-in floating point (which would explain the difference in precision), but the programmers of whatever game assumed that the Applesoft BASIC floating points worked the same way as the Apple II floating point. That would explain things, thanks -- I've never worked directly with 6502 assembly. I'm used to floating-point being implemented only in an interpreter or compiler on platforms that old. This game also has some low-level routines written in 6502 assembly. All actual game logic is written in BASIC, though, which was odd even 35 years ago.
|
|
#
?
Dec 20, 2020 23:35
|
|
|
The iOS app I'm working on is a native version of a web app we have, and I'd like to avoid a lot of duplication when it comes to i18n. The web app uses a library based on FormatJS, so our locale files look like this:code:
|
|
#
?
Dec 21, 2020 14:46
|
|
|
awesomeolion posted:I'm imagining Zucc having to 2fa into Facebook's developer account to accept the latest terms update... If they avoid shared accounts then they literally are messaging that one person who has 2fa setup to do the thing each time? That's hard to believe for some reason but I've never worked at a large org But of course jokes aside, the account holder doesn't have to be Zucc. The account holder is just someone set up to be responsible for the company's developer account. And that someone logs in from their own Apple ID. I think the terms require that the account holder just has the legal authority to accept agreements on behalf of the company.
|
|
#
?
Dec 21, 2020 15:18
|
|
|
|
| # ? May 15, 2024 11:25 |
|
|
prom candy posted:The iOS app I'm working on is a native version of a web app we have, and I'd like to avoid a lot of duplication when it comes to i18n. The web app uses a library based on FormatJS, so our locale files look like this: I don't know of one. Unless I'm mistaken, the localization machinery of .strings and .stringsdict files, bundles, etc. is mostly a black box, so you'd be reimplementing a lot yourself. (Though there might be a an open source implementation in swift-corelibs-foundation if you want a reference.) My suggestion is to find/make something that turns the .json files into .strings/.stringsdict files as a build phase. Then you can use all the existing localization features in Foundation while keeping a single source of truth. The only trick I can think of there is you won't have string keys available, just ordered parameters, so e.g. instead of {name} you'd have %1$@. Could always put the original FormatJS string as a comment so it's close by.
|
|
#
?
Dec 21, 2020 17:18
|
|