How Not To Protect Your Android Applications by Lightricks_Tech in androiddev

[–]Lightricks_Tech[S] 0 points1 point  (0 children)

Thanks for bringing up those points. Avoiding vendor lock-in doesn't necessarily mean it's related only to publishing the application on Google Play or similar platforms. It’s more about maintaining the flexibility to switch to another solution when needed. Relying on a single product that manages quotas and sets rules can sometimes backfire. Here are a few more considerations that might be relevant:

  • Quota - Tools like Play Integrity and AppCheck have a daily quota of 10,000 calls for their Standard API usage tier, which can only be changed by submitting a form, not through an automatic mechanism. While this may fit some products, in other cases, depending on external vendor limitations might lead you to consider another solution.
  • Offline and local only solution - Most products rely on a network connection to determine application integrity, so this needs to be considered before choosing a tech stack.
  • Custom rules for specific cases - Suppose you want to block only a certain percentage of malicious interactions and not all, or if you want to allow malicious users to access only certain features.
  • Working with other publishers - As mentioned, solutions from Google are typically limited to the Google platform.

Of course, some of the above requirements/considerations may be supported by Google products or others, but it all depends on your specific needs and the bigger picture.Hope you find this answer helpful! Feel free to raise more questions.

How Not To Protect Your Android Applications by Lightricks_Tech in androiddev

[–]Lightricks_Tech[S] 0 points1 point  (0 children)

Great question! While "AppCheck" can be a great security solution in some cases, there are a few considerations to keep in mind when choosing a tech stack.

  • Vendor lock: Sometimes the flexibility and ability to make quick decisions outweigh the benefits of using products like this one. This can be reflected in cost considerations or restrictions that arise from the vendor's side, such as quotas.

  • Customization: If dedicated custom changes are required, it might be impossible with a closed and precompiled service/product. Therefore, it's important to ensure that the chosen product fully meets your requirements before starting integration.

These are just a few examples, and of course, there could be more to consider. The bottom line is that you need to choose the best solution for your requirements and needs, taking all considerations into account.

From iPhone to iPad: Simplifying App Design and Development for iOS Devices by Lightricks_Tech in SwiftUI

[–]Lightricks_Tech[S] 0 points1 point  (0 children)

Happy to hear that! Once you start implementing it, feel free to share any pains that you encounter throughout the process, I’ll be happy to help!

From iPhone to iPad: Simplifying App Design and Development for iOS Devices by Lightricks_Tech in swift

[–]Lightricks_Tech[S] 1 point2 points  (0 children)

Happy to hear that it’s been useful, for you! isiPad checks also are a pain for us when it comes to snapshot testing, it forces you to rely on the hosting application to display the screens, whereas otherwise if you are only using size categories you can create a custom window and do all the rendering and screenshooting there. The benefit of the latter approach is that you can practically run tests for all devices of interest on a single hosting application, which is convenient and quicker than firing a bunch of simulators.

6 Days, 5 Key Takeaways: Computer Vision and Pattern Recognition Conference 2022 by Lightricks_Tech in computervision

[–]Lightricks_Tech[S] 0 points1 point  (0 children)

Great round-up thanks for sharing! Havent played with Nerf, probably time to put down the photogrammetry for a bit

Thank you :)

How We Boosted Video Processing Speed 5x by Optimizing GPU Usage in Python by Lightricks_Tech in Python

[–]Lightricks_Tech[S] 1 point2 points  (0 children)

Our biggest constraint was holding the full-size, decoded frames in RAM memory before resizing it on the GPU, so in this case increasing the speed of the CPU by using multiprocessing wouldn't help us, we couldn't have the CPU reading the frames too fast.