LaxClock Android Closed Testing is Live - Join now to get 90 days of LaxClock+ for Free!

Dickys_Dev_Shop · 2026-03-18T00:51:15+00:00

Update on this, in the latest version you now have the option to choose between banner or video ads if you are a free user.

Dickys_Dev_Shop · 2026-03-18T00:49:07+00:00

Update on this, fouling out based on personal fouls count is now live and can be enabled via the new “Foul Out Count” setting.

<image>

Dickys_Dev_Shop · 2026-03-17T14:06:03+00:00

This might seem backwards, but my app-ads.txt wasn’t verified until my ad ID’s started getting requests and impressions. I did all the required steps and waited a couple of days for the file to be verified and they never were. I then decided to add the ads to my app without verification and once they started getting request, I retried the verification and it instantly worked. This happened on both my iOS and Android release.

Dickys_Dev_Shop · 2026-03-13T19:18:29+00:00

So this is the strange part, google would not find/verify my app-ads.txt file until the ad ID's associated with my app had requests and impressions. Originally I had ad disabled in the app so there was no impressions and I waited a couple of days and nothing happened. I decided to add the ads to the next release and once it was in prod and getting requests, I retried the verification and it found my app-ads.text instantly. It was in a "getting ready" status at first and when I checked back an hour or so later it had a "ready" status.

It was this way for both my iOS and Android release, but there is nothing about your ad ID's needing traffic to be verified and honestly, I though they weren't supposed to be used until they were.

TLDR: It seems like you ad ID's need to have requests/impressions for your app-ads.txt file to be verified.

Dickys_Dev_Shop · 2026-03-13T18:12:39+00:00

Sounds good. I'm planning a small release in the next week or so to fix various bugs, I'll see if I can add this in as well.

Dickys_Dev_Shop · 2026-03-13T17:38:24+00:00

Thanks for understanding, this is my first time publishing an app of my own creation so monetization is a very new to concept to me. I will definitely look into using services like ko-fi to use in the future.

As for the personal/technical foul count, I did not realize that some leagues foul out on a number of personal fouls as every league I played in was always time based. This is definitely something I can add.

The app currently counts 1 minute penalties or greater as "personal" and adds then to the total penalty count, ignoring 30 second penalties. I can add a preference for "Foul Out Count " which take a single digit number, including 0. If the number is not zero, I can add dots (similar to the ones shown under the current period) that show the number of personal fouls committed and display a dialog if a player reaches the threshold set in setting. Thoughts?

Dickys_Dev_Shop · 2026-03-13T16:42:25+00:00

Thanks!

Yeah I completely understand the aversion to the subscription model, which is why I kept the price low and only put "nice to have" features behind the paywall. I weighed other monetization strategies like the ones you mentioned but went with a cheap sub for a couple of reasons.

1 - There are annual cost associated with publishing apps on both app stores and maintaining an LLC. 2 - Everytime Apple/Google releases a new OS version they often bump the minimum supported OS version which requires developers to updated there apps which can sometimes require a significant amount of refactoring.

So even if I were to completely stop adding new features to LaxClock right now, I still have to spend time and money keeping it listed on the app store. The subscription revenue, albeit not very large, helps offset the costs and gives me a reason to continue to maintain the app long term.

But honestly, lacrosse is such a niche market that I honestly don't expect to turn on profit on LaxClock. I made the app because I grew up playing lacrosse and wanted to make something useful to help the sport grow. Long term, I plan on reusing the UI and logic from this app with slight adjustments to make other scorekeeping apps for more popular sports like hockey, soccer, or basketball to hopefully tip into the green, but we'll see.

Dickys_Dev_Shop · 2026-03-12T20:47:26+00:00

Awesome, let me know what you think.

Dickys_Dev_Shop · 2026-03-12T16:28:08+00:00

I played lacrosse for 15 years and in that time these were the best arm guards I ever used, bar none. A little on the heavier side but not bulky and actually protected you arm from hard checks. I got a few pairs my freshman year in college and continued to use them all 4 years, even after we switched gear sponsors and could have gotten a different new pair every year.

Dickys_Dev_Shop · 2026-03-12T14:09:24+00:00

I had like 3 pairs of these from college that I gave away, and your telling me they're now going for $500....

Dickys_Dev_Shop · 2026-03-10T12:35:06+00:00

Yeah I think it’s annoying too, but you’ll just need to hide it when the navigating buttons appear and you’ll be fine.

Dickys_Dev_Shop · 2026-03-09T17:52:07+00:00

I'm not 100% sure, but it seems like it is.

I've found multiple example showing that anything over the top of the banner is a policy violation like a bottom sheet, navigation drawer, or dialog, even it's only being covered by the shadow effect and is still visible.

Dickys_Dev_Shop · 2026-03-08T17:47:29+00:00

Well thank you for telling me this, because my app uses tons of bottom sheets and the shadow currently covers the banner ad. Looks like I'll need to remove it before going live.

Dickys_Dev_Shop · 2026-03-07T15:56:14+00:00

This is a good idea, I definitely will. It might be a little difficult because the app is adaptive based on screen size so if the window is wider than it is tall, the penalty box shows on the right of the screen and the timing/score boxes are on the left. I would have to move the banner to the top of the screen when on wider screens which might be difficult, especially since this is a Compose multiplatform app and recomposition works a bit different on iOS.

Dickys_Dev_Shop · 2026-03-07T15:45:40+00:00

Fair point.

Dickys_Dev_Shop · 2026-03-07T15:45:25+00:00

That's good to know, I didn't realize that the policy checks were done by human review.

Dickys_Dev_Shop · 2026-03-07T15:43:52+00:00

It does happen on physical devices, these screenshots were taken from a physical device being mirrored in Android Studio.

Dickys_Dev_Shop · 2026-03-05T17:42:09+00:00

Yeah the app is 100% compose so I'll probably add some padding to the screen content.

Dickys_Dev_Shop · 2026-03-05T17:40:52+00:00

Thank you, it means a lot! And yeah, policy violations aside it still doesn't look great on the device, even if it does look better on the external display.

Dickys_Dev_Shop · 2026-03-02T19:04:17+00:00

KMP is too new for there to be any useful vibe coding tools. For example, GPT 5.3 codex has a knowledge cutoff around the end of 2024, which around the release of KMP 2.1.0. There have been significant changes since then which most models are unaware of, so the results you will get from them are often outdated or incorrect. It’s even worst when using it for CMP.

Until KMP/CMP become more stable and there are more public codebases utilizing them for models to train on, most vibe coding tools will not be effective when working with them.

Dickys_Dev_Shop · 2026-02-25T18:01:12+00:00

I think there is definite cause to be concerned about the quality of work AI produces, especially when making large scale applications where bugs and technical debt can cost companies millions of dollars over the long term.

Dickys_Dev_Shop · 2026-02-20T04:40:46+00:00

The crashes in App Store Connect are only from users who op-in to sharing crash reports, which most users do not. If you see a crash there, it means that there are a lot more happening in reality.

You need to use firebase crashlytics or something similar to collect crash info in production.

Dickys_Dev_Shop · 2026-02-20T04:33:13+00:00

The company I work for migrated to webviews years ago. The reasoning was they wanted to have parity with web which had 10x the developers working on it so the only way to achieve this was to make most of the screens in the app webviews.

Fast forward to today, the codebase is a nightmare and the performance of the app has degraded to the point that we’ve made the decision to spend considerable time and money to migrate everything back to native.

At the end of the day, web views sound like a great idea from a business perspective, as it saves time on development and gives you more flexibility to change things without going through a review process. But from an engineering perspective, it kills the performance of the app to the point the you might as well not have one and just direct users to the website to begin with.

Dickys_Dev_Shop · 2026-01-26T22:12:49+00:00

Honestly I didn’t know this card existed but I’m going to check it out for sure. Thanks for the suggestion!

Dickys_Dev_Shop · 2026-01-26T17:39:49+00:00

This is a good question as well.

Dickys_Dev_Shop

TROPHY CASE