|
Dog on Fire posted: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. It ends up being a huge pain for client services, where the people making the app and shepherding it through App Store Connect do not have any relevant legal authority.
|
#
?
Dec 21, 2020 17:19
|
|
|
|
| # ? May 15, 2024 01:18 |
|
|
pokeyman posted: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. Yeah, that may be the way to go. I don't want to swim upstream too much here. Thanks!
|
|
#
?
Dec 21, 2020 18:09
|
|
|
pokeyman posted: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. That’s what I’d recommend too, including putting the original key in the comment of the strings file. Xcode’s localization export/import machinery will propagate that into the XLIFF it generates so the localizer will see it too.
|
|
#
?
Dec 21, 2020 20:29
|
|
|
I'm a little surprised no one has mentioned the new Small Business Program. Getting a 15% increase in revenue is really a big deal, and I'm happy that Apple is doing this. Just got my notice today.
|
|
#
?
Dec 23, 2020 17:47
|
|
|
lord funk posted:I'm a little surprised no one has mentioned the new Small Business Program. Getting a 15% increase in revenue is really a big deal, and I'm happy that Apple is doing this. Just got my notice today. It’s actually a 21% increase in revenue!
|
|
#
?
Dec 23, 2020 23:02
|
|
|
jabro posted:It’s actually a 21% increase in revenue! Math! Good point.
|
|
#
?
Dec 23, 2020 23:22
|
|
|
lord funk posted:I'm a little surprised no one has mentioned the new Small Business Program. Getting a 15% increase in revenue is really a big deal, and I'm happy that Apple is doing this. Just got my notice today. I'm definitely happy it happened. Just can't speak to the experience as I just do ecommmerce stuff. I've actually never put anything out on the app store under my name. Maybe I should change that in 2021.
|
|
#
?
Dec 27, 2020 06:35
|
|
|
I mostly do web development, is there an Xcode version of a simple secrets/config JSON file that isn’t added to source control?
|
|
#
?
Dec 28, 2020 21:33
|
|
|
Centrist Committee posted:I mostly do web development, is there an Xcode version of a simple secrets/config JSON file that isn’t added to source control? Ooh I also mostly do web development and just went through this! Ultimately this article helped me get everything I needed to get set up, but some other reading I did lead me to believe that actually storing secrets in your iOS app bundle isn't secure. There are methods of obfuscation but it seems like similar to shipping it with a JS web app, someone can reverse engineer it and grab your API keys or whatever. I still needed to set up environments for API endpoints and public API client IDs, but I moved some of the actual secret stuff (like OAuth) to the server. Someone else might have a better answer/more info on the security of storing actual secrets with your bundle
|
|
#
?
Dec 28, 2020 23:34
|
|
|
This is a good rundown: https://nshipster.com/secrets/ Ultimately you can’t stop someone who wants them from getting your API keys etc. but you can do a little bit. If you want to keep secrets out of source control then I like using an ignored .xcconfig that I conditionally include from another .xcconfig. Then your build still works if someone doesn’t have secrets.
|
|
#
?
Dec 28, 2020 23:53
|
|
|
Like anything else you should assume: 1. The client is a filthy liar and nothing it sends you can be trusted 2. A determined attacker can read anything and everything you ship in your app bundle no matter how "clever" you believe you are being
|
|
#
?
Jan 8, 2021 07:59
|
|
|
I'm trying to set up fastlane for ditribution of an enterprise app. match made a new iOS Distribution certificate, and a universal distribution provisioning profile for an existing bundle id. I built the ipa via gym with the export_method being enterprise. It was distributed to a test ipad via jamf but it just shows up greyed out. From my understanding of provisioning profiles and certs this ipa should work. Is there anything common I might be missing? google is pretty useless. Edit: Turns out my tester's ipad was on iOS 13 and I had updated to target iOS 14. So completely unrelated to cert stuff. KidDynamite fucked around with this message at 18:29 on Jan 11, 2021 |
|
#
?
Jan 11, 2021 18:06
|
|
|
It's been a while since I started on a new app, is Firebase the preferred way to get analytics and so forth?
|
|
#
?
Jan 12, 2021 06:14
|
|
|
No analytics is my preferred approach  Firebase is still a thing and seems to work ok.
|
|
#
?
Jan 12, 2021 08:38
|
|
|
pokeyman posted:Firebase is still a thing and seems to work ok. Just curious if there was something else that's preferred these days?
|
|
#
?
Jan 12, 2021 16:58
|
|
|
All I ever wanted was crash reporting. Crashlytics >> Fabric >> Firebase just became a sea of bloat that I didn't want any part of.
|
|
#
?
Jan 12, 2021 23:07
|
|
|
The actual crash reporting part has seemingly gotten worse over the years too. I only get to see crash reports second-hand but the stuff that does get forwarded to me is way less useful than what we got a few years ago.
|
|
#
?
Jan 13, 2021 01:18
|
|
|
I also don't get analytics. The one time I went to WWDC I was floored how often devs were talking about sales analytics. In the 11 years I've had stuff on the App Store I've looked up my total sales once.
|
|
#
?
Jan 13, 2021 02:41
|
|
|
Is it considered bad practice to nest core controllers? I'm coming from React where everything is component based, so if you have something on screen that's fairly complex you can isolate all of its behaviour into another component and maybe just pass in a couple of callbacks from the parent. I have a view controller in my iOS app that's getting pretty chunky and I'd love to slice off some of the parts of it into separate view controllers. Or maybe they would just be views? Regardless this file is approaching 1000 lines and it doesn't feel good.
|
|
#
?
Jan 13, 2021 15:14
|
|
|
Child view controllers are cool and good! Just make sure the callbacks you pass in don't create a strong reference cycle.
|
|
#
?
Jan 13, 2021 16:21
|
|
|
Y'all are smart, so maybe you can point me in the right direction here. I have an audio thread running C code that references an array of floats (it's a sound waveform). I would like to update that array with new values from the Swift side / main thread. code:
|
|
#
?
Jan 17, 2021 17:37
|
|
|
You can’t load and store a variable from different threads without some kind of synchronization. That goes for both array references and their individual elements. There are some sophisticated techniques here that avoid using a lock, but if you’re not very comfortable with threads, I would just use a lock. Try to acquire it for very short periods, just long enough for a few loads and stores.
|
|
#
?
Jan 17, 2021 19:46
|
|
|
I think I'm headed towards the sophisticated techniques. Locks are pretty verboten in audio, and there's a link there to a circular buffer that I think is what I'm looking for.
|
|
#
?
Jan 17, 2021 22:56
|
|
|
Okay. Well, the recent atomics library includes a lock-free lazily-initializable (but not subsequently changeable) strong reference which you can use to form a singly-linked queue through objects. Or if a circular buffer works, then all the better.
|
|
#
?
Jan 18, 2021 01:08
|
|
|
Is it kosher/smart to do things like subclass UILabel to manage consistent text styles? ie a Heading class that just sets a color, font, size, alignment etc on initialize? I'm trying to represent our design system in this app a bit better and reduce repetition.
|
|
#
?
Jan 20, 2021 16:40
|
|
|
It's probably the easiest way if you wanna use them in storyboards and xibs, yeah.
|
|
#
?
Jan 20, 2021 17:46
|
|
|
I don't, is there a better way if I want to do everything programmatically?
|
|
#
?
Jan 20, 2021 17:49
|
|
|
prom candy posted:I don't, is there a better way if I want to do everything programmatically? Subclassing is a fine idea. Alternatively you could make a label formatter object that you could pass them through.
|
|
#
?
Jan 20, 2021 18:11
|
|
|
I'd probably add factory methods in extensions, e.g.code:code:It's mostly a code style thing though, I doubt anyone familiar with the platform would have the slightest confusion with a HeaderLabel subclass etc.
|
|
#
?
Jan 20, 2021 18:12
|
|
|
lord funk posted:Subclassing is a fine idea. Alternatively you could make a label formatter object that you could pass them through. are there any advantages to a formatter object approach? I can't think of any.
|
|
#
?
Jan 20, 2021 18:12
|
|
|
ketchup vs catsup posted:are there any advantages to a formatter object approach? I can't think of any. Testing? Use off the main thread?
|
|
#
?
Jan 20, 2021 18:13
|
|
|
I guess maybe reuse of labels too. It might be fine if the only time you format them is initialization, but in a reusable view that might become an issue.
|
|
#
?
Jan 20, 2021 18:15
|
|
|
NSAttributedString gets me like 90% of the way there. It's rare that I feel the need to change numberOfLines or minimumFontScale after init.
|
|
#
?
Jan 20, 2021 18:17
|
|
|
pokeyman posted:I'd probably add factory methods in extensions, e.g. This is super cool, thanks! I like how this lets you at a glance still see that the underlying object is a UILabel and also probably more easily find styling options in the auto complete.
|
|
#
?
Jan 20, 2021 18:18
|
|
|
To throw out another option, you could pass a style struct or enum into an initializer extension: UILabel(style: .header) There are pros and cons to each approach, but any of them would be fine if all you need to do is set a few properties. Subclassing can get hairy if you end up needing to subclass for other purposes, since you'll be forced to pick a single style for that subclass. But it's also the most flexible for customization since you have the ability to override APIs. I wouldn't overthink it though, just go with the approach that you find most natural / pleasant that fulfills your requirements.
|
|
#
?
Jan 20, 2021 18:35
|
|
|
pokeyman posted:Use off the main thread? I hadn't considered this, and it reminded me to be much more thoughtful about how I use the main thread. thanks!
|
|
#
?
Jan 20, 2021 18:42
|
|
|
I'm hitting a performance wall with SwiftUI on macOS and looking at implementing a piece of the view hierarchy in raw AppKit to control table and collection view reuse in a granular fashion. Curious if anyone has thoughts or experiences and might have input. I profiled the app in Instruments and saw that even after overriding `id` in the top-level list, CPU usage is high inside of the UI framework. So my idea is to write this stuff imperatively with the hopes of reusing the row views as much as is possible. I wonder though if perf is bad because of the layout calculations and not because of allocations. Perhaps I should re-open Instruments and observe another run. Jam2 fucked around with this message at 19:42 on Jan 21, 2021 |
|
#
?
Jan 21, 2021 19:40
|
|
|
I'm not an expert in this, but a couple things stand out. First, body isn't necessarily only called on "semantic" updates, so overriding id like that might be really problematic. Second, does it help at all if you flatten the results/indices list up front, either when assigning to results or in the argument to List?
|
|
#
?
Jan 21, 2021 21:54
|
|
|
Those aren't lazy afaik so it's gonna create all 2000 even if they aren't onscreen. They added some much-needed lazy stuff but it's not available in 13  https://developer.apple.com/documentation/swiftui/lazyvstack Also yeah you shouldn't be doing whatever that is with the id Edit: to be more specific the state variable changing should be enough to cause a ui update. I think the only thing setting the id manually is gonna do there is cause it to create new views instead of re-using and updating contents, which is probably bad for performance. brand engager fucked around with this message at 01:42 on Jan 22, 2021 |
|
#
?
Jan 22, 2021 01:38
|
|
|
|
| # ? May 15, 2024 01:18 |
|
|
I think there’s supposed to be some laziness about those loops when the elements are fixed-size, but that might not have ever been real.
|
|
#
?
Jan 22, 2021 03:34
|
|