mergeconflict379 === [00:00:00] James: Welcome back everyone to a fun filled merge conflict, your weekly developer podcast, talking about all things in the world of developer y things. Sometimes NET, sometimes the Apple vision pro, sometimes open source software, sometimes, uh, in app billing plugins and just general in app billing APIs that change every year. I am one of your hosts, uh, who is in a okay mood today, James Montemagno. And with me as only, as always. As only, as always, the one and only Mr. Frank Krueger. How's it going, [00:00:30] Frank: buddy? Yes, I try to never leave your side. I try to always be there for you whenever you need me. I respond to your texts the moment you send them. I am just on top of things. And I'm in a great mood, even though I'm completely exhausted. I had to do some physical work today, and so my body's tired, but I am ready to talk about technology, because that's what we do. We talk about technology, but mostly programming. And mostly NET. Okay, we have our niches. Yeah, it's [00:00:58] James: true. Um, it is true, but today I do want to talk about Android. Uh, we have three topics today. I have two. And in the time that we do those two, Frank has come up with the third. So will he stick around until the end to find out if Frank comes up with topic number three. Oh my God. If people don't know, we, we basically do zero planning for this podcast. The, our planning is our lives. So things that are happening in our lives become the podcast. And I think that's really exciting. I mean, it kind of makes it. You know, spontaneous, but there are some planned things like events, obviously, like when build and dub dub and big releases come out and iPhones are, you know, breaking and setting on fire because the titanium, those are great things to talk about. However, Frank, I want to bring up and talk about. In app billing again, because [00:01:49] Frank: I thought you were joking. I thought there was no way we were talking about this. [00:01:54] James: Nope. I was. So as one does with their partner is you often are taking along drives together and you talk about in app billing libraries and specifically Google in app billing. because I often, I, I build the in app billing plugin and my wife's company, she's head of mobile engineering. So like she deals with this stuff like all the time. So we talk about Google's restrictions and requirements now in this call, we've just doubled down on how much we enjoy. Now, Apple could screw us all over by the way, next release, but I don't think they will. I here's my problem, Frank. Google has decided in their righteous mind to release a new version of in app billing every single year. And they decide that you have one or two years to upgrade to that version, or you cannot release your app. Now they're not going to turn off the spigot, maybe at some point. But you're not even allowed to update your application. And they're big breaking changes. And here's the thing. I use zero of these new features. I have one in app billing thing to purchase and one subscription. I don't have free trials. I don't have promos. I don't have like groupings. I have all this stuff. I think I'm in the 99 percent of applications that have like one thing to buy, two things to buy one subscription, not a big deal. And even big companies, right? Like big applications have like a subscription. You know what I mean? It's like not a huge thing. I want to talk about. The ethics behind this, and am I just, am I, am I like, like, is it, is it okay? Because here's the thing, here's the thing, here's why I hate making the in app billing library that's cross platform. Which is it. It's because it deals with money and I don't want to mess with people's money. Every year, Google is messing with money. And it's very upsetting. This is a new thing. And here's the thing. I have to go through all this code and it's all the APIs, it doesn't get worse. There's nothing better to them. They're more complex, more advanced. Do the same freaking things. Which is by a product to restore a purchase, give me a product back. Why do I need phases and changes? Why are they changing? Product SKUs to products. Like, why, why, why are you doing it? It's so upsetting. What would Miguel de Acaza say? [00:04:30] Frank: Dang. Well, I mean, it's, it's an ding. It's an ad company. Of course, they're going to mess with your money. All they do is play little margin games. Like, Ooh, if I charge this person 25 percent and that person 27%, we have a 2 percent uh, arbitrage and we're profitable. This is how big. Companies think this is why you should never work with big companies. But anyway, um, it's just Google. They're notorious. They don't care about anything. Um, is it ethical? No, let me, let me just get to the, let's, let's get there right in the beginning. Um, no, every time, look, I'm even going to take a bigger stance. I don't even care that it involves money. You API. Ever. I don't care if you're using SemVer or not, you are not allowed to break an API. If you decide, in your vast wisdom, to increase your major version number and break an API, that's a bug. You are introducing a bug into everyone's app. And you have to decide, is your single person's time more valuable than thousands of other people's time? Or, are you not a conceited jerk? You have to make that decision at some point. And when you've made that decision, you'll see, don't break an API. Ever. That said, you know, sometimes global warming happens, wars break out, sometimes you gotta change an API, you bump up the semver. But you cannot do it every year. So, no, it's unethical, they're a big group of jerks, and I'm just gonna say it. Because someone has to. This modern world of breaking libraries every year, just for fun. Like this happens, I've been doing a little bit of the JavaScript world and the Java world is particularly nasty because not only is there a new framework invented every year, everyone's got to switch to that, but libraries come and go and libraries don't keep up with the latest run times. And if you let a node app sit for. I'm going to say about a year, maybe two years. It's going to be very difficult for you to get that thing up and running again, just from packages missing and libraries moving on, incompatibilities with the OS, things like that. So in general, the whole modern movement toward semver and breaking APIs, I'm just going to say it. Everyone who does that is a big jerk, and please stop doing it. Uh, rant over. Please tell me more, James, about how to be a jerk. [00:06:59] James: The problem, and the problem is, is like, every time that they break the API, I have to break my API, basically. Like, there's no sometimes ways around it. And I even had someone reach out to me, you know, at Microsoft. I was like, hey, like, I'm getting ready to upgrade because I can't upgrade my app. I can't even release an app upgrade. Until I upgrade your thing. Is it against V six? And I was like, yeah, it's against V six. Like, were there any changes? I was like, I was like, well, there, the, the a p I surface, I did an additive change, so, you know, I had a default. Okay. Con I added a default, um, mat, uh, constructor, uh, sorry, A default parameter. So your API's compatible. [00:07:37] Frank: No, not good enough. Um, you can't put a by default. Do you mean it's initialized to a value? Yes, correct. That's not good enough. Um, because in NET we ship our apps compiled IL. It's not compiled down to native. It's compiled to IL. You have introduced a new parameter into that constructor that makes it a completely different constructor from what they're linking against. So if they're at a code level, NET MAUI. Then they can recompile against your library without a change? Yes. But at a binary level, you just broke [00:08:11] James: every app. [00:08:12] Frank: That is correct. Correct. And that matters. It does matter because, um, okay, so if someone's referencing you, bueno, everything's fine. If someone's referencing someone who references you, [00:08:28] James: That's a good point. No, I didn't think of it like that. That's a, good point. Don't add param [00:08:32] Frank: adding parameters is a breaking change. And see rant number one, breaking changes are not allowed. I [00:08:39] James: guess I almost, I know, I guess you're right. So I guess I would have had to introduce. a second [00:08:45] Frank: constructor, an overloaded [00:08:47] James: constructor. Oh man. Yeah. Okay. That's there you go. And the more you learn, I mean, I probably knew that now that you say it now it makes sense, but it's like, it was like, oh, there's evil. Yeah. [00:08:54] Frank: Well, the other thing too is... All of your additive... Yeah. No mutation, the additive. [00:08:58] James: Yeah. Well then what I told them, I was like, well, that's the only change to like methods if you upgrade the library, which you'll have to, and just reference me directly. That's the only thing that was changed. I said, except all of Android subscriptions change a hundred percent because Google changed everything at a hundred percent. And someone was like... Someone was like, and here's the fun part is like, someone was like, there used to be a property called free trial length, and that's no longer there. Like, how do I get access to that? And I said, Oh, Google remove that. And they prefer that you parse the string that you set it. So they, they recommend you, you do product ID. 30D or one W or one w, M or whatever. Right? And you parse the string yourself. What? [00:09:46] Frank: And I was like, wonderful change, totally worth breaking, change and making it worse. Perfect. [00:09:51] James: Yeah. So anyways, it's, it's delightful and changing ever. And it just kind of upsets me because, um. It's like I have, and the thing is I have like no reason to upgrade my application. Like my application is good. It's running, like I'm not really, it's in kind of maintenance mode. And to me, this is what upsets me about it is like. It's in maintenance mode and it's like, good. Like it's ready for the fall season. [00:10:17] Frank: That's a big corp term. Don't use maintenance mode. It's in. The app does what I designed it to do and it doesn't have any outstanding bugs. [00:10:25] James: The app is stable and it's doing what I want it to do. And I'm not, I'm not, I'm not. If I wanted to add new features, the feature I wouldn't want to add is a rewrite all of the in app billing and retest all of it. Right? Like the thing works perfect. Like if then, then Heather and I are discussing, we're like, well, here's the cool, interesting part about Apple. They have store kit, which is not a great API in general. It it's been around from the beginning. And you know what they've done? It's everything has been additive. They have all this new junk that I don't care about. I don't even care. I didn't want it. I expose it because it's new. I put the conditions around the blah, blah, blah. It's all new. It's all good. It's all additive. They changed nothing else. Now they have store kit too. If you want to rewrite all of your in app billing, you can. I know at some point. They're going to force us to do it, right? But in all of the years of StorKit, guess what? It works exactly the same. [00:11:27] Frank: Yeah. Um, uh, not, not to play silly games, but like how often have you had to update the iOS side of your in app billing generic plugin? Never, [00:11:38] James: I've only updated experience to add new features. [00:11:40] Frank: That's it. Yeah. Okay. So if they, yeah, what did they do? They did like limited subscriptions or time limited subscriptions, things like that. Yeah, they added, okay. [00:11:48] James: They, they added like more metadata, so like you could grab more metadata. You could like open a subscription page or do a bunch of other like little, like open some store page or like see if someone, You can like see if there's like a Boolean that says like, does this account have access to the stores? If it's like a kid's account, right? It wouldn't have access. Right. So that's a Boolean you could check ahead of time. I didn't know about that one. Yeah. So that's kind of cool. You can say, Oh, is, are you able to even buy stuff? And if you're not, then I'm not going to prompt up the screen. Cause it'll just give you an error or whatever. So. Yeah, I know it's not [00:12:18] Frank: the greatest API, but like, um, every time I would go to you and we've certainly discussed it on the podcast plenty of times, I keep saying these things are just shopping carts. Like, you know, let me access the inventory. Let me post an order and let me get a confirmation that the order succeeded and everything else I can handle. And yet they just keep on insisting on making things more complex. Uh, yeah. It's [00:12:46] James: like when you go to home, yeah, well, it's like, it's like you're saying, like, and like, you also want to like retrieve all of the receipts for a user account. Like when you go to Home Depot and you want to return something, they scan the receipt, which is your user ID. For all intents, it's a transaction ID, but you have it. And they're like, cool, done returned. You know what I mean? Like, we know that you bought this thing on this thing and it pulls it up. And it's just a database. Like I'm like, do that thing. That's all I want. [00:13:13] Frank: Yep. Yep. Um, now the sad thing is like, I was just thinking, okay, small side tangent here. I was playing. What if, what if, what if the world was different? What if history was a little bit different? And the, what if game that I was playing was what if the app store. wasn't based on stupid iTunes and selling music. What if the Apple engineers had actually decided to write a new app store that had, you know, app specific things like trials and, you know, demos and betas and things like that? It's not the world we live in. Instead, the world we live in is we got a very messed up version of iTunes in order to sell our apps in, which had zero features for apps. In app purchases weren't even there in the beginning. That's why all my apps were paid for. And I, And it's also why none of the apps ever had trials, because you don't trial music. You, you get a 30 second version of it, but they won't even let us post 30 second versions of our apps. So it, the what if game really annoyed me because I kept thinking, I'm like, wow, they're, I don't, it's not laziness. We all know how big corporations work and building a website is actually difficult, but I'm just going to say laziness. The laziness to reuse the iTunes System for purchasing apps really, really defined history. I blame a lot for bringing the price of apps down to zero to where we all have to do the free meal model now and then fine. They could have supported the free meal model, but they don't. So we're supposed to use subscriptions and in app purchases to do the free meal model. It's all just kludges on kludges on kludges because of stupid history. And because we got the wrong branch in the what if game. So, um, why do they keep, I, I agree that they should keep adding to it because, yeah, in app purchases are very important, it's the only way to make money on the App Store, mostly these days, but it, it still doesn't give Google any, any right, any right to change the API, they're just Conceited. Yeah, whatever. Yeah. That's [00:15:30] James: like, I feel like that's the problem. Yeah. It's like when things are so, when things are so stable, right. They're already forcing you to upgrade your app for the latest come a compilation and all this other stuff. And like, that's a minimum bar and eventually like to delist your app. And it's like, okay, I get it. Like you want active apps, you want this stuff. But it's like, again, what if the app is literally doing and running perfectly? Exactly how I want it to be. And that's my, my problem at the end of the day, let my users complain that they haven't gotten any updates because the app shows a number on the screen. That's what it's supposed to do. That's all I wanted to do, Frank. All right. Topic number two, topic number two, I did a video on it. It's called new get. NuGet Central Package Management. You know about this? Have you heard about it? Have you heard the news, Frank Krueger? [00:16:14] Frank: I thought you even mentioned this on the podcast at one point, but I've already forgotten, but I'm pretty sure I like it, but I've already forgotten what it does. James, I didn't watch your video. Give us [00:16:26] James: the quick version. Let's say Frank, you're building an application. And it has more than one project. It has, you know, class libraries. It's got a backend. It's got a front end. It's a, it's an application. It's got, it's got stuff. Now, let this, the problem is that the, here's the problem. The problem is that when you want to update your NuGets. You got three, four, five projects, right? And you have to go update all of them. Go into the package references pack. Hopefully you're not using packages config, please don't. But you got to go update that. You got to use the GUI. You got to use the command line. You got to open the files, do a thing. And pretty much all you're doing is just updating them all to the same exact version. So they all match up. Just like you said earlier, you want your. Them to be especially using class 1, 2, [00:17:16] Frank: 2. Don't mix the versions. It's, [00:17:18] James: it's really bad, bad stuff. . So what if Frank, you could just have a single file. Mm-hmm. that instead of having packaged references, defined package versions. [00:17:31] Frank: Ooh, I like it because I already invented this six years ago. No big deal. , you actually had to deal with it. Um, you would. There was a period of time where you were helping me out with Continuous, my IDE. And I had this funny F sharp script in it called SetVersions. And you're like, Frank, what is the SetVersions thing? I'm like, James, that's how you set the versions. And you're like, why can't I just update the nougats? And I'm like, no, you can't update the nougats. It's a very fragile, very sensitive project. It's very sensitive about all of its versions. And it was, um, the project was really complex because I'm sure like. Most people's big projects. You have a whole bunch of your code. A whole bunch of code you copy and pasted because there was no NuGet. You had to put it in there. And then you have 8 billion NuGets coming into your project that also provide code. And so you just have all these different sources of code and getting them all in sync was very difficult. And I just threw up my hands at one point and wrote a terrible script that, given a list of version numbers, would just Dig into every project, just mercilessly, crack open every project file and just go find all the versions and update all the versions. Really great, um, I'm Glad they're baking it in. I actually do have a different solution I've been using these days, but this solution's better. Um, should I mention the other one, or should you tell us some more about this version thing first? [00:18:58] James: Well, I'm curious if the thing that you were using was the same thing that I was using, which was directory. build. props? That's the hacky old way of doing it, yeah. Yeah, and I, in [00:19:11] Frank: general, I, I consider it a hack too. Um, a lot of people who love MSBuild would say these are not hacks, these are things designed to work this way, yeah, these are features for MSBuild. Where I disagree with that is I really don't like global environment settings. So if my project is dependent on a file outside of the directory of the project and that dependency is implicit. I don't like, I don't like implicit. I don't like magic. I don't like things going to find things, but this NuGet package problem is such a big deal that, uh, the easiest solution, everyone, uh, go create a, what is it called directory dot props or directory dot build dot props, whatever, something like that. Go look up the documentation. Uh, what's lovely about that thing is you can just put in a whole bunch of NET MAUI. Properties. And it's, it acts like a little csproj file that gets merged into all your project files. And that way you can set all these properties really, uh, consistently between a bunch of projects. And you can even, uh, thanks to package ref, force a bunch of nougats into all projects. But that's the kicker. That's the bad spot. Yeah. Every nougat you list in there. is going to get added to every project, which is probably not what you want. And that's why I'm actually, um, happy to hear that they're doing something a little smarter. That's just versions, not the packages themselves. [00:20:41] James: Am I getting that right? So you can, yeah, that's correct. Yeah. So you can define like, let's say you define five package versions of Of, uh, five different new gets then in project one, maybe that has all five. So you'll still do a package reference. And you'll say, include Newton soft dot JSON, but you just leave off the version because the version is implied by the package version now in the other project, maybe it's only using two. So it only brings in two. Bingo Bango. Now here's the kicker. Now there's a bunch of rules and you can override and you can have nested, you know, directory. packages. props, right? So it's kind of the same thing as you were doing, but here's the kicker is if you're using NET 7 or 8, you can use something called global package references. It goes in the same file, but imagine you want a nougat in every single project. So before you would do it, you are doing it exactly, but you can mix and match these. So you can say, here's all the package versions. And then here are global package references that go everywhere in every single project. So that's pretty cool. That's my, that's my jam. [00:21:48] Frank: And it is actually pretty cool because there, there's not too big of a downside to referencing a package, even if you don't use it. The downside on iOS is that package will come with you. If it doesn't get linked out, it'll increase the size of your executable, but it doesn't increase the size of a DLL or anything you could add. 8, 000 references in there, and the DLL size will only go up by the name of the files. The functions. Yeah. Um, so, that's cool. Uh, cause I could easily see me throwing all the JSONs and all the things in there. Actually. I manage my own new project templates. I'm going to throw one of these into my new project template. And all my projects are going to get all the things, because you know what? I just don't care anymore. Add all the libraries. I want all the libraries. Every time I have to write code, I get angry these days. So just bring them all in. Can I just say NuGet star? Can I just bring in everything? [00:22:50] James: You can, you can do, um, you can do like star, like, you know, like versions or whatever that works as well. So if you're like, give me everything 8. 0. star or whatever, it'll figure that out. But that would be, uh, [00:23:03] Frank: It's funny because I was just dealing with this too in continuous that has the magic set version script that does all this stuff for me. I think all my versions are perfect, right? I get to the end of a 37 minute build because that's how long it takes to build this stupid thing. Get to the end and it's like, Hey buddy, uh, we see you wanted F sharp core 5. 0. 1, but we're going to bring in 6. 0. 1. Cuz. And I'm like, but why? And they're like, cuz. And I'm like, but why? And they're like, cuz. And I'm like, okay, fine. So, like, even with my strict system, I still somehow get random versions of things. And so, I'm definitely going to give this, um, a little spin to see if it can at least fix my stupid F sharp core version, because that one's tripping me up. I have no idea why it's so Messing up the versions there. [00:23:57] James: That's wild. Yeah, it's, it's a pretty cool feature and it's something that I didn't know about and I was working on some stuff for Donnet Comp and we're in this repo and I was like, oh, what is this? I'm like, what is this file? And it's kind of cool too. 'cause like let's say you're doing as P Donnet core, like a lot of the version numbers are the same, right? Yeah. So let's say you have like a bunch of a p, you have like eight, so it's still, you still can define variables up top. So you could say like ESP nine net core version, right? You can still define. And then reference them with like a dollar sign below. So you could basically be like, here's all of my ASP. NET ones and they're all referencing this version. So that's kind of cool is you can just bump it in one place and then it just trickles down. So it's kind of cool. [00:24:36] Frank: Ooh, I like that. Now I'm getting scared though. Sounds like someone put some effort into this, uh, configuration language. Sounds like it's growing up to be a programming language. Great. It's always good when that happens. [00:24:46] James: Yeah, it's pretty cool. [00:24:49] Frank: So how, how out of date? We, James, is this a T net six feature? Seven eight. When to come out [00:24:56] James: The T six feature? Yeah. . Sonet six. [00:24:59] Frank: Okay. Everyone's high . [00:25:01] James: Yeah. Breaking T net six for the package version. Nette seven for the global packages. So not too far. Okay. [00:25:10] Frank: You know, honestly it's like two years. It's uh, I don't even feel too bad. I was um, I got the funniest email from Azure the other day and it's all like, Hey, buddy. I'm like, Hey, what's up Azure? And it says, I see you're running a NET 6 app. I'm like, yeah, living in the future. And it's like, that's the past. That's the past, buddy. You know what the future is? NET 8 LT. You're on NET 6 LT. Long term here at Microsoft means a year and a half. So, uh, we're going to need you to upgrade to NET 8, which actually hasn't been released yet. And I'm like, great, buddy. You're really, really stressing me out here. [00:25:47] James: I got, I saw your tweet and I got, I got an email that was like, Hey, you're on NET 7. You need to update to NET 8. I have inside baseball that I can't talk about on the podcast and we'll talk about after I hit stop. Um, but I have, I have a whole, I sent a whole email out to some people about that. I'll be like, wait a second, what's going on here? [00:26:06] Frank: Not so bad. Like it really isn't so bad because, um. I did post, I was slightly nervous because like NET 3 wasn't compatible with NET 6, even a NET 3 app, it wouldn't run in NET 6. But I think somewhere around NET 6 is where we stopped being incompatible with old versions, so it should be like 6, 7, 8 should be really easy to bounce between. It's the ones before 6 that can cause scariness and late night nightmares, things like that. But even those, most of those go over just fine. I recently converted a NET 3 app over to NET 6 and that was fine too. But it was just funny. I'm like, it's a year and a half email. Azure, calm, calm yourself down. [00:26:54] James: It's pretty great. All right, I got the last topic because I know you don't have one. Unless you got one. I had [00:26:58] Frank: one. I, you don't have to complain. I was going to complain. [00:27:02] James: I'm ready. Go ahead. Bring it on. Oh, two old guys complaining on the podcast. [00:27:06] Frank: This is a perfect three minute topic here. We'll bring this in to 30 minutes on the dot. Can I complain for a moment? Because I know I already have to. Well, all right. Test flight app review. Did you know, James? Did you know? Let me finish here. Did you know that they are reviewing our apps in TestFlight AppReview [00:27:27] James: now? Yeah, that's correct. [00:27:29] Frank: They never were before. Man, I've uploaded the junkiest junk to TestFlight and they would get approved immediately. I always just assumed there was a computer or Siri. Maybe Siri is doing it. Siri's just like, oh, nice icon, approved. And I just assumed that that's how the TestFlight approval system worked. Now I know that's not true because... Something weird happened maybe two years ago, one year ago, app reviews started being faster than test flight app reviews. It was the weirdest switch. I was waiting on an Uh, test flight app review to happen. And I'm like, you know what? This is a solid build. I don't even, I'm not even going to do a beta round for this build. I'd been doing betas before. I'm just going to do a release now. And the release was approved in like four hours and the test flight was approved two days later. So I'm just like, what is going on over there? And then recently I had an app rejected. So it's all just coming to my head of like, I remember when TestFlight first came out. We're like, Apple, please don't put an app review on there. That's not the point. We want to get betas out. And they're like, no, don't worry. We're just going to look for high level, important stuff. It's going to go right through the beta check. It's going to be super fast. And man, they're just not coming through on that promise. TestFlight app reviews are horrendous. There shouldn't be rejections on there for anything that's not like just deleting the user's data. [00:28:57] James: Uh, yes. I remember this specifically because it's with, it's mostly with new apps and that's the biggest thing. And Google does the same thing, by the way, especially for new apps that you create. And if it's your first time doing anything, which the first time you're going to do anything is to internal alpha, internal testers, test flight testers, right? And really what you, what you're doing there is you're like, I want to try to get it on to hardware and into users to test X, Y, Z, you know what I mean? I found in my testing in recent, recently launching a new app, which I know, I don't know, I guess, well, iCircuit3D was the last one you released, which was, I guess, a while ago [00:29:40] Frank: now, right? Yeah. Yeah. Yeah. I'm due. I'm due for an app. [00:29:44] James: And, and between that, like, I remember the Google one taking like. 10 days or something like that for them to approve it. It was like a week or something like that. It was wild. For the beta, for the app, for the store. Beta, just the beta, just the beta. Wow. Wow. And then it took, it took, it took a good amount of several days to actually for them to approve it into the store. Um, cause I think like either process is the same, basically like, Oh, this is a new thing. We're going to like actually go through a process. is wild. And the same thing on TestFlight is like just sitting there like, what is going on? I don't understand. Like it was, yeah, it's like two or three, four days. I is wild. Um, I. I didn't get rejected though, but, uh, that's, [00:30:24] Frank: I don't want to complain. I just, it just feels weird to me. Like the app store was always a scary place because you could work on an app for three months, go through the app store review. I've literally done this myself and they're like, Nope, not going to take your app. You change it as much as you can. They're like, Nope, Nope. We're just not going to take your app. And then what do you do? You're stuck not selling your app. So. If what they're doing is running that same level of review to where if it passes test flight app review, most likely it'll pass real app review, great. But I just don't think that's the case. I think what we have are, um, little kings ruling over their little kingdoms and enjoying their little power when they really should just be clicking the approve button and not really. doing anything else. And so I think what the real problem I have is I don't have a mental model of what TestFlight is anymore because my apps aren't finished when I put them on TestFlight. Exactly what you said. I use TestFlight to test hardware because like provisioning is hard and it's annoying. And it's much easier for me to just do a TestFlight build and get it down to my own test devices and things like that. They make, uh, I should say this is all for external testing. The internal testing is still instant. Thank goodness. That's true. Yeah. Yeah. But, um, I don't own every device under the planet. Some of my friends own devices I don't have and I want to test on their devices and therefore I want to do external builds also. Um, so this is just a short rant on TestFlight. It's not so fun anymore. It used to be fun. Like you said, once your app is approved, once that version has been approved, then the computer kicks in and just starts auto approving you. But that first one, it's ugly. And they, they really, like, I keep getting quoted on performance sections of the guidelines. I love how they always have to dig up a stupid section of the guideline to prove their, to justify their, yeah. And I keep getting performance and they're like, I don't know how to use your app, but I don't know what your app does. I'm like, how does, what does that have to do with performance? Yeah. Such a broken system. Anyway, that's complaints [00:32:36] James: over. I'm curious if they think that it's, if they just let anything in there, then people will use it as like an app distribution store for friends. You know what I mean? [00:32:46] Frank: Dang, that app store is full of scam apps. All the top selling, all the top profiting apps on the app store right now are scams. Go look at the list. They are just, they're like, hey, give us 50 bucks and we're gonna blink some lights at you. And that's what they do. And those apps are allowed in. But I can't get a stupid basic app through a beta test. Yeah, you can, you can steal as much money from users as you want. That's allowed. But you know, don't you dare show a blank screen. [00:33:17] James: The number one app right now in the world is money. No, this is actually really surprising. Top free app is it's called laps. It's a disposable camera, social, social, uh, disposal for friends. I guess you take photos every day. And then Timu. Which is, uh, things that are really cheap. These [00:33:41] Frank: are top profits, top [00:33:42] James: money. How do I find that? [00:33:46] Frank: Well, it used to be easy. There used to be, um, um, top paid apps used to be the way you do it. But now you have to go find, um, top, um, gross, top, there, there's something. You can find it. [00:34:01] James: I'm looking, apps you might like. There's so many categories. I know I don't even go in the app store. Yeah, exactly. Top paid apps. [00:34:09] Frank: Yeah, that used to be the way you find out. But now with in app billing, top paid apps is not representative of the top [00:34:16] James: earners. Yeah, that's true. No, the top earners are. Yeah, I'm imagining it's a top app that it's probably also a top earner because like, I bet if I go, that's the problem. [00:34:30] Frank: No, a lot of apps are scam apps that are just profiting off of, well, they're profiting off of users in ugly ways. They're the kind of apps that are like, um, Hey, this is free. But in order to do anything, you got to try this one month thing that's going to charge you 15 and they auto subscribe you and then you stay subscribed. Those kinds of scams. [00:34:56] James: Scam alert! Um, well, on that scam note, uh, let me end on some cool stuff that's going on in the world. All right. Got NET Conf happening. Check out dotnetconf. net. I think the schedule is going to be out. By the time this podcasts out, we'll see. [00:35:16] Frank: They had dates announced. Can you say the dates? [00:35:18] James: Yeah. November 14th to the 17th. Nope. Great. To the, yeah. Net comp. 14th to the 16th. 14th. 15 16th. Net 14 15 6. Comp net. They just announced the student zone. If you're a student, a learner, you got to out the student zone. It's pretty cool. It's the day before on the 13th, a cool promo trailer. I'm in it a bunch with my long hair, but I do want to give a shout out to the Visual Studio channel. Frank, uh, youtube. com forward slash visual studio. Now tomorrow, when this podcast is out, the podcast, this podcast is out on the ninth, on the 11th. So two days later, you can go to the youtube. com forward slash visual studio. We'll talk about it next week too. There's this mini series called tea and technology. I prefer to call it coffee and technology. I don't know. Um, I am others seven. There's seven episodes, like a TV series, that for every week new things get released. Um, they're T, their mini series where Richard Campbell from NET Rocks interviews seven different people in and around different parts of Visual Studio NET, other technologies, talking about their story, talking about all sorts of things. I get to talk about creating mobile apps and my journey, which I've talked a little bit about here. Uh, and. I, Frank, busted out the floppy disks and you're going to see some floppy disk code. You're going to see some beautiful C code. You're going to see, I got permission. From the game studio that I worked at to get some footage and some code that I wrote from some shader code in this puppy. So pretty excited about that. And I talk a little bit about Dot Net Maui and Xamarin days. Things, things of your, so episode four, October 13th, it's about 12 minutes long. So it's not a big commitment, but it's good stuff. I'm excited about it. I'll tweet about it on the 11th. It's out. [00:37:20] Frank: I used to always love Channel 9 stuff, so this reminds me a lot of that. And you look like a big ol hippie, and that's with your long hair and your unshaven [00:37:29] James: beard. It's very long, yes. It's happening, in general. So, well, that's it. I just want to end on that note, I'll put a link in the show notes to the blog, talking about it, give it a look. So until... Next week, this has been another Merge Conflict. I'm James Montemagno. [00:37:48] Frank: And I'm Frank Krueger. Thanks for watching and listening. Peace.